Power distribution area edge computing task dynamic offloading method, device and storage medium

Abstract

The application discloses a power distribution area edge computing task dynamic unloading method and device and a storage medium, relates to the technical field of power edge computing, and comprises the following steps: at least one candidate gateway meeting the required computing power and delay constraint of each subtask in a subtask list is screened out from a real-time updated neighbor resource table; the target gateway of each subtask is determined according to the working condition information of each candidate gateway; a response sequence is generated according to the subtask list and the target gateway of each subtask; a remote call request of each subtask is generated according to the response sequence, and the remote call request is sent to the corresponding target gateway through a Hongmeng distributed task scheduling framework and a Hongmeng distributed soft bus to execute the subtask; and if all the subtasks are successfully executed, the results are combined. The application can reduce edge task processing delay and improve resource utilization balance.

Description

Technical Field

[0001] This invention belongs to the field of power edge computing technology, specifically relating to a method, device and storage medium for dynamically offloading edge computing tasks in a power distribution area. Background Technology

[0002] With the increasing number of distributed photovoltaic (PV) systems, charging piles, energy storage systems, and various monitoring sensors connected to distribution transformer substations, the types and scale of data that need to be processed on the substation side are constantly increasing. Edge devices not only need to complete basic data acquisition and protocol conversion, but also need to undertake computational tasks such as load forecasting, power quality analysis, and operational status identification. Compared with traditional simple reporting scenarios, these tasks place higher demands on processing timeliness and local computing power, especially when PV output fluctuates, load changes suddenly occur, or multiple types of devices report data simultaneously, the edge side can easily experience computational pressure in a short period of time.

[0003] Currently, in edge computing scenarios such as distribution transformer areas, edge gateways typically handle data acquisition and computation independently, lacking real-time resource status sharing and collaborative scheduling mechanisms between devices. When a gateway receives a large number of computation tasks in a short period, it is prone to problems such as insufficient local computing power, excessively long task queuing times, and increased response latency. Meanwhile, other idle gateways cannot participate in sharing the workload in a timely manner, resulting in uneven load distribution and low resource utilization within the distribution transformer area. Furthermore, existing solutions lack fine-grained matching of task characteristics and device operating status when handling tasks with different time requirements and computational complexities. This can easily lead to high-priority tasks failing to respond in a timely manner or experiencing delayed abnormal recovery, thereby affecting the real-time performance and reliability of edge task processing.

[0004] Therefore, in edge computing scenarios for distribution radio areas, how to improve the real-time performance of task processing, the balance of resource utilization, and the reliability of anomaly handling in a multi-device environment without increasing the complexity of deployment and operation and maintenance has become a technical problem that needs to be solved. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the present invention aims to provide a method, device, and storage medium for dynamic offloading of edge computing tasks in distribution radio areas, thereby achieving precise resource matching and orderly distributed execution based on subtask granularity, reducing task processing latency, and improving system reliability.

[0006] This invention provides a method, device, and storage medium for dynamically offloading edge computing tasks in distribution radio stations, comprising:

[0007] At least one candidate gateway is selected from the real-time updated neighbor resource table that meets the required computing power and latency constraints of each subtask in the subtask list; the subtask list stores multiple subtasks of the source gateway's unloaded task.

[0008] Based on the operating status information of each candidate gateway, determine the target gateway for each subtask;

[0009] Generate a response sequence based on the subtask list and the target gateway of each subtask;

[0010] Based on the response sequence, remote call requests for each of the subtasks are generated, and the remote call requests are sent to the target gateway of the corresponding subtask through the HarmonyOS distributed task scheduling framework and HarmonyOS distributed soft bus, so that the target gateway executes the corresponding subtask; if all the subtasks corresponding to the task to be uninstalled are executed successfully, the execution results of each subtask are merged to obtain the task output result.

[0011] The steps for updating the neighbor resource table include: receiving device information from multiple edge gateways in real time; establishing communication connections with the multiple edge gateways located in the target distribution area via the HarmonyOS distributed soft bus based on the device information, and designating the edge gateways as neighbor gateways; periodically receiving resource status data from the neighbor gateways via the HarmonyOS distributed soft bus; dynamically updating the neighbor resource table based on the resource status data of each neighbor gateway; and deleting the neighbor gateway from the neighbor resource table if no resource status data is received from any neighbor gateway for a duration exceeding a preset offline time threshold.

[0012] The operational information includes idle CPU rate, packet loss rate, current queue length, and historical average response time; determining the target gateway for each subtask based on the operational information of each candidate gateway includes calculating the comprehensive matching score of each candidate gateway according to the following formula: ;in, This represents the overall matching score corresponding to the i-th candidate gateway; This represents the idle CPU rate of the i-th candidate gateway; This represents the packet loss rate between the source gateway and the i-th candidate gateway; This represents the current queue length of the i-th candidate gateway; This represents the historical average response time of the i-th candidate gateway; , , and These represent the weighting coefficients corresponding to the idle CPU rate, the packet loss rate, the current queue length, and the historical average response time, respectively. The target gateway for each subtask is determined based on the comprehensive matching score, and the total computational load of all subtasks allocated to the same target gateway does not exceed a preset proportion of the remaining computing power of the target gateway.

[0013] The response sequence includes the expected return time for each subtask; the method further includes: if the subtask execution result is not received from the target gateway of the corresponding subtask after the expected return time, the subtask execution is determined to have timed out, and the subtask is designated as an abnormal subtask; the abnormal subtask is added to the head of the pending task queue of the source gateway, and a target gateway is re-matched for the abnormal subtask based on the neighbor resource table.

[0014] The step of generating remote call requests for each of the subtasks based on the response sequence, and sending the remote call requests to the target gateway of the corresponding subtask through the HarmonyOS distributed task scheduling framework and the HarmonyOS distributed soft bus, includes: determining the target gateway, input data, and service identifier for executing the current subtask based on the response sequence; initiating the remote call request for the current subtask to the target gateway through the HarmonyOS distributed task scheduling framework based on the service identifier and the input data; and sending the remote call request to the target gateway through the HarmonyOS distributed soft bus, so that the target gateway executes the current subtask based on the service identifier.

[0015] Before selecting at least one candidate gateway from the real-time updated neighbor resource table that satisfies the required computing power and latency constraints of each subtask in the subtask list, the method further includes: real-time monitoring of the operating status of the source gateway and the queue of tasks to be processed; the queue of tasks to be processed includes multiple unfinished tasks, each of which includes an estimated computing load and an elapsed waiting time; based on the operating status and the queue of tasks to be processed, determining whether the source gateway satisfies any of the set of task unloading triggering conditions; if so, selecting a queue of tasks to be unloaded from the queue of tasks to be processed to generate the subtask list.

[0016] The operating status includes CPU utilization; the task unloading triggering condition set includes at least one of the following task unloading triggering conditions: the CPU utilization of multiple consecutive sampling points is greater than a preset CPU utilization threshold; the waiting time of any of the unfinished tasks is greater than a preset waiting time; the estimated computational load of the newly allocated unfinished tasks is greater than the remaining computable load of the source gateway.

[0017] The queue of tasks to be uninstalled includes multiple tasks to be uninstalled, each task including input data, business priority, and task type; the step of generating the subtask list includes:

[0018] The maximum allowable delay of the task to be uninstalled is determined based on the business priority of any task to be uninstalled in the task queue.

[0019] Based on the input data, task type, and estimated computational load of each task to be uninstalled, determine whether the corresponding task to be uninstalled is a splittable task.

[0020] If the task is divisible, the current task to be unloaded is divided into multiple independent subtasks according to the amount of input data. The input data slice and subtask data amount of each subtask are determined according to the input data of the current task to be unloaded. The required computing power is determined according to the subtask data amount of each subtask. The latency constraint of each subtask is determined according to the maximum allowable latency of the current task to be unloaded. A corresponding service identifier is assigned to each subtask according to the task type of the current task to be unloaded to generate the subtask list.

[0021] The present invention also provides a computer device, comprising: a memory configured to store instructions; and a processor configured to retrieve the instructions from the memory and, when executing the instructions, to implement the method described above.

[0022] In addition, this application also provides a machine-readable storage medium storing instructions that cause a machine to perform the method described above.

[0023] This invention discloses a method, device, and storage medium for dynamically offloading edge computing tasks in a distribution network. By constructing a dual gateway screening mechanism based on subtask granularity, it first uses a real-time updated neighbor resource table to perform baseline filtering on candidate gateways based on computing power and latency constraints, effectively eliminating nodes lacking the capacity to handle tasks and reducing invalid offloading attempts. Then, it calculates a comprehensive matching score by combining multi-dimensional operating condition information such as idle CPU rate, packet loss rate, queue length, and historical response time, and applies load balancing constraints to ensure that subtasks are accurately allocated to the currently optimal target gateway, reducing execution latency caused by node congestion or poor link quality at the source. Based on this, by mapping the subtask list to the target gateway as a structured response sequence, and relying on the HarmonyOS distributed task scheduling framework and HarmonyOS distributed soft bus to initiate remote calls, it achieves the orderliness of cross-gateway task distribution, the accuracy of data correspondence, and the standardization of service calls. Simultaneously, it introduces an anomaly monitoring and queue head rollback rescheduling mechanism based on expected return time, enabling timed-out subtasks to be identified and re-matched with available resources in a timely manner, significantly improving the system's fault tolerance and task processing continuity in dynamic environments. In summary, this application effectively solves the technical problems of high task processing latency, uneven resource utilization, and delayed anomaly recovery in edge computing scenarios while ensuring the integrity of the results. Attached Figure Description

[0024] Figure 1 This is a flowchart of the dynamic unloading method for edge computing tasks in distribution radio stations according to an embodiment of this application;

[0025] Figure 2 This is a schematic diagram of the computer device structure according to an embodiment of this application.

[0026] Among them, 101-select candidate gateways from the real-time updated neighbor resource table, 102-determine the target gateway based on the operating condition information, 103-generate response sequence, 104-generate and send remote call request, 105-merge subtask execution results, 210-memory, and 220-processor. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application.

[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0029] like Figure 1 As shown, this embodiment provides a method for dynamically offloading edge computing tasks in a distribution radio area. This method is applied to the source gateway and aims to solve the problems of high task processing latency and uneven resource utilization in edge computing scenarios of distribution radio areas. The method includes the following steps:

[0030] Step S101: Select at least one candidate gateway from the real-time updated neighbor resource table that meets the required computing power and latency constraints of each subtask in the subtask list; the subtask list stores multiple subtasks of the active gateway's unloaded task.

[0031] Specifically, the neighbor resource table is a dynamic data table maintained locally by the source gateway. It records snapshots of the current resource status of surrounding neighbor gateways, including but not limited to CPU idle rate, memory availability, and network round-trip latency. The table's contents are updated in real-time as neighbor gateways report their status; it is not statically configured. The subtask list is a structured set of tasks generated by the source gateway after parsing and breaking down the originally large number of unloaded tasks. Each subtask carries constraints such as the computing power threshold required to execute that task segment and the maximum allowable latency. In this step, the source gateway traverses the neighbor resource table, comparing the real-time capability metrics of each neighbor gateway recorded in the table with the constraints of the subtasks. Only gateways with sufficient remaining computing power to support the subtask computation and whose network communication latency meets the subtask's timeliness requirements are retained as candidate gateways. This process essentially constitutes the first "feasibility filtering" mechanism. Its technical effect is to exclude gateways that are online but have excessive load or poor link quality, and cannot guarantee timely task completion, from the decision-making scope in advance. This avoids the invalid communication overhead and inevitable timeout failure caused by sending tasks to unavailable nodes, and lays a reliable data foundation for subsequent accurate scheduling.

[0032] Step S102: Determine the target gateway for each subtask based on the operating status information of each candidate gateway.

[0033] Specifically, in the candidate gateway set obtained after step S101, although each gateway meets the basic execution threshold, their actual service capabilities still differ. Operating condition information refers to multi-dimensional status data that characterizes the current operational health and service performance of the candidate gateways. This includes not only static resource reserves but also dynamic factors such as task queue backlog, historical average response speed, and link packet loss rate. The source gateway comprehensively evaluates and ranks the candidate gateways based on this operating condition information, selecting the gateway most suitable for undertaking the corresponding sub-task as the target gateway. This process constitutes the second "optimized matching" mechanism, which differs from traditional random allocation or simple polling strategies and can perceive the real-time micro-state of nodes. Through this mechanism, sub-tasks are preferentially directed to nodes with lighter current loads, more stable communication, and faster response times, thereby reducing the risk of task queuing and network transmission jitter at the physical level and significantly improving the success rate and execution efficiency of task offloading.

[0034] Step S103: Generate a response sequence based on the subtask list and the target gateway of each subtask.

[0035] Specifically, the response sequence is a structured scheduling control data that transforms the discrete decision results determined in the preceding steps into a standard instruction flow that can be recognized and executed by the system. When generating the response sequence, the source gateway maps and encapsulates each subtask in the subtask list with its corresponding target gateway identifier, input data location index, expected return time, and service identifier. This serialization process ensures that each subtask distribution has clear addressing information and execution context, resolving potential object confusion, data mismatch, or out-of-order timing issues that may occur during concurrent multi-task distribution. It should be understood that the specific data structure of the response sequence can be adjusted according to the actual communication protocol, as long as it fully carries the core scheduling semantics of "which subtask is sent to whom, what data is used, and when a return is needed." By constructing the response sequence, this application transforms complex distributed offloading decisions into an ordered linear control flow, greatly enhancing the controllability and standardization of the task distribution process.

[0036] Step S104: Generate remote call requests for each subtask based on the response sequence, and send the remote call requests to the target gateway of the corresponding subtask through the HarmonyOS distributed task scheduling framework and HarmonyOS distributed soft bus, so that the target gateway executes the corresponding subtask.

[0037] Specifically, the source gateway parses each record in the response sequence and converts it into a remote call request conforming to the HarmonyOS ecosystem specifications. In this process, the HarmonyOS distributed task scheduling framework and the HarmonyOS distributed soft bus play a crucial collaborative role: the HarmonyOS distributed task scheduling framework is responsible for the logical orchestration at the task level. Based on the service identifier in the request, it locates and initiates the corresponding atomic service or application capability on the target gateway, achieving cross-device "capability invocation" rather than simple "message passing"; while the HarmonyOS distributed soft bus is responsible for establishing the underlying communication link and data transmission. It provides a low-latency, highly reliable transmission channel for remote call requests, shielding the differences in underlying network protocols. Under this architecture, the source gateway does not need to concern itself with the specific hardware address or underlying connection details of the target gateway; it only needs to complete cross-node task dispatch through a standardized framework interface. This invocation method based on HarmonyOS native capabilities not only ensures compatibility between heterogeneous devices but also further reduces scheduling overhead through system-level optimization mechanisms, making real-time collaboration at the edge possible.

[0038] Step S105: If all subtasks corresponding to the task to be uninstalled are executed successfully, the execution results of each subtask are merged to obtain the task output result.

[0039] Specifically, because the task to be unloaded is broken down into multiple subtasks and executed in parallel on different gateways, the final business result is inevitably fragmented. Once the source gateway confirms that all subtasks have returned valid results on time, it reassembles these partial results according to a pre-defined merging logic. For example, for data analysis tasks, this might involve weighted aggregation of the statistical values ​​returned by each subtask; for image processing tasks, it might involve splicing and restoring the recognition results of each block according to their spatial location. The merging operation is triggered only when all subtasks have executed successfully. This ensures that the final output is semantically complete and accurate, avoiding erroneous decisions due to missing tasks. This step completes the closed loop from "distributed execution" to "centralized delivery," allowing upper-layer business applications to obtain high-quality computational results equivalent to local execution without needing to be aware of the underlying unloading and splitting details.

[0040] Through steps S101 to S105 described above, this embodiment constructs a complete dynamic offloading backbone process for edge computing tasks in distribution radio stations. This process ensures the accuracy of offloading decisions through a dual-screening mechanism, guarantees the orderliness and efficiency of distribution execution through response sequences and the HarmonyOS native framework, and ensures the integrity of service delivery through a result merging mechanism. Thus, without increasing additional hardware costs, it effectively improves the overall throughput and real-time response performance of the edge computing system.

[0041] Furthermore, the dynamic update mechanism of the neighbor resource table and the target gateway selection and matching logic based on operating condition information are described in detail. The steps for updating the neighbor resource table include: receiving device information from multiple edge gateways in real time; establishing communication connections with multiple edge gateways located in the target distribution area via the HarmonyOS distributed soft bus based on the device information, and treating the edge gateways as neighbor gateways; periodically receiving resource status data from neighbor gateways via the HarmonyOS distributed soft bus; dynamically updating the neighbor resource table based on the resource status data of each neighbor gateway; and deleting a neighbor gateway from the neighbor resource table if no resource status data is received from any neighbor gateway for a period exceeding a preset offline time threshold.

[0042] Specifically, the construction and maintenance of the neighbor resource table is a runtime, dynamically aware process, rather than relying on pre-burned static configuration files. The source gateway utilizes the HarmonyOS distributed soft bus's device discovery and service announcement mechanism to automatically identify edge gateways online within the same target distribution area. When an edge gateway connects to the network, it actively broadcasts device information containing a unique identifier, IP address, and its distribution area information. Upon receiving this information in real time, the source gateway authenticates the edge gateway via the HarmonyOS distributed soft bus and establishes a point-to-point communication connection, subsequently adding it to the neighbor gateway list. This soft bus-based automatic discovery mechanism enables the system to be plug-and-play, adapting to changes in devices within the distribution area without manual intervention. After establishing a connection, the source gateway periodically receives resource status data reported by neighbor gateways at preset time intervals (e.g., 5 seconds). This data covers key indicators such as CPU idle rate, memory availability, task queue length, network round-trip time (RTT), and packet loss rate. The source gateway updates the corresponding records in its local neighbor resource table in real time based on the latest received data, ensuring that the table reflects the actual service capabilities of neighbor gateways in the vicinity at the current moment. Furthermore, to prevent "zombie nodes" caused by device power outages or network failures from interfering with offloading decisions, this embodiment introduces a timeout removal mechanism. If the source gateway does not receive any status report from a neighboring gateway within a preset offline time threshold (e.g., 15 seconds), it determines that the gateway is disconnected or unavailable and removes it from the neighbor resource table. This mechanism effectively ensures the freshness and accuracy of the data source used for subsequent filtering and matching, avoiding invalid waiting and resource waste caused by distributing tasks to actually unavailable nodes.

[0043] After completing real-time maintenance of the neighbor resource table, the source gateway performs optimal matching of the target gateway based on operational information. Operational information includes idle CPU rate, packet loss rate, current queue length, and historical average response time. These dimensions together constitute a multi-dimensional vector for evaluating the comprehensive service capabilities of candidate gateways. Idle CPU rate represents the current remaining computing resources, packet loss rate represents the stability of the communication link, current queue length represents the immediate task backlog, and historical average response time reflects the gateway's performance baseline when handling similar tasks in the past. To quantitatively evaluate the suitability of each candidate gateway, this embodiment uses the following formula to calculate the comprehensive matching score of each candidate gateway: ;in, This represents the overall matching score corresponding to the i-th candidate gateway; This represents the idle CPU rate of the i-th candidate gateway; This represents the packet loss rate between the source gateway and the i-th candidate gateway; This represents the current queue length of the i-th candidate gateway; This represents the historical average response time of the i-th candidate gateway; , , and These represent the weighting coefficients corresponding to idle CPU rate, packet loss rate, current queue length, and historical average response time, respectively.

[0044] In this formula, and As a positive gain term, it means that the more abundant the resources and the more stable the link, the higher the score; while and As a negative penalty, this means that the longer the queue and the slower the historical response time, the lower the score. Weighting coefficient to It is not fixed, but can be dynamically adjusted or pre-configured based on the business characteristics of the tasks to be unloaded. For example, for latency-sensitive tasks, the value can be appropriately increased. and The value of makes the system more inclined to select gateways with fast historical response times and stable links; while for computationally intensive tasks, it can be increased. The weighting of parameters prioritizes the supply of computing power. Through this configurable weighted scoring mechanism, this application can flexibly adapt to diverse edge computing service needs and implement differentiated scheduling strategies.

[0045] Furthermore, to avoid overloading and crashing a high-scoring gateway by concentrating too many subtasks on it, this embodiment introduces load balancing constraints. Specifically, the target gateway for each subtask is determined based on its overall matching score, and the total computational load of all subtasks assigned to the same target gateway does not exceed a preset proportion of the target gateway's remaining computing power. This preset proportion is typically set to 80%, designed to reserve a certain resource buffer for the target gateway to handle sudden traffic surges or system overhead. When the total computational load of subtasks intended for a target gateway exceeds this threshold, the excess subtasks will be automatically assigned to the next best candidate gateway, thereby achieving load balancing at the cluster level.

[0046] To illustrate the above optimal matching process more intuitively, a specific numerical example is provided below. Assume that source gateway A currently has a short-term load forecasting subtask to be offloaded, and after initial screening, candidate gateways B and C are obtained. A query of the neighbor resource table shows that gateway B's IP address is 192.168.1.102, its idle CPU rate is 75%, its free memory is 512MB, its packet loss rate is 0.1%, its current queue length is 2, and its historical average response time is 20ms; while gateway C's IP address is 192.168.1.103, its idle CPU rate is 30%, its free memory is 256MB, its packet loss rate is 0.3%, its current queue length is 8, and its historical average response time is 50ms. Weighting coefficients are then set. Substituting the values ​​into the formula, we can see that gateway B's overall matching score is significantly higher than gateway C's because it not only has ample computing power but also a short queue, fast response, and stable link. Therefore, the system prioritizes gateway B as the target gateway. Next, load balancing verification is performed, assuming the estimated computational load for each subtask is... FLOPs, a total of 20 subtasks need to be allocated, with a total computational cost of FLOPs. If the remaining computing power of gateway B is estimated to be... FLOPs, with an 80% capacity limit. FLOPs. Since the total computational load does not exceed this limit, all 20 subtasks can be safely assigned to Gateway B. Conversely, if the number of subtasks increases to 50, the total computational load will reach [a certain threshold]. If the number of FLOPs exceeds the safe carrying capacity limit of gateway B, the system will allocate the first 48 subtasks to gateway B, and the remaining 2 subtasks will automatically overflow and be allocated to the second-best gateway C. Through this dual guarantee mechanism of "rating and optimization + capacity fallback", this embodiment ensures that tasks are allocated to the current optimal node, effectively prevents the risk of single-point overload, and significantly improves the overall stability and task processing success rate of the edge computing cluster.

[0047] Furthermore, the exception handling mechanism and the specific implementation of remote invocation based on the HarmonyOS ecosystem are described in detail. The response sequence includes the expected return time of each subtask; the method also includes: if the subtask execution result is not received from the target gateway of the corresponding subtask after the expected return time, the subtask execution is determined to have timed out, and the subtask is treated as an exception subtask; the exception subtask is added to the head of the pending task queue of the source gateway, and a target gateway is re-matched for the exception subtask based on the neighbor resource table.

[0048] Specifically, the expected return time is a time base set for each subtask in the response sequence. It is not arbitrarily set but calculated comprehensively based on the subtask's latency constraints, task type, and network transmission and scheduling overhead. For example, for an image recognition subtask with a latency constraint of 200ms, considering network round-trip latency and processing fluctuations at the target gateway, the expected return time can be set to 1.5 times the latency constraint, i.e., 300ms, to provide a reasonable tolerance window. When the source gateway starts a timer after issuing a remote call request, if no valid feedback is received within the expected return time, the system automatically determines that the subtask has timed out and marks it as an abnormal subtask. This determination process is entirely triggered automatically by the system at runtime, requiring no manual intervention, thus ensuring the real-time nature of anomaly detection. More importantly, for identified abnormal subtasks, this application does not simply discard them or place them at the end of a normal queue, but instead inserts them at the head of the source gateway's pending task queue. This "head rollback" mechanism gives abnormal subtasks the highest rescheduling priority, allowing them to be processed again before newly arriving normal tasks, effectively avoiding the accumulation of overall business latency due to a single execution failure. Subsequently, the source gateway will re-match the target gateway for the abnormal subtask based on the latest neighbor resource table. Since the neighbor resource table is updated in real time, the re-matching process can avoid faulty nodes or congested links that might have previously caused timeouts, selecting a more optimal execution node in the current state. This significantly improves the fault tolerance and business continuity of cross-gateway task execution. In an optional implementation, a retry limit (e.g., 3 times) can be set for the abnormal subtask. If the limit is reached and the task still fails, it is marked as a failure and reported in the logs to prevent infinite retries from consuming system resources.

[0049] Furthermore, regarding the underlying implementation of remote calls, remote call requests for each subtask are generated based on the response sequence, and these requests are sent to the target gateway of the corresponding subtask via the HarmonyOS distributed task scheduling framework and the HarmonyOS distributed soft bus. This includes: determining the target gateway, input data, and service identifier for executing the current subtask based on the response sequence; initiating a remote call request for the current subtask to the target gateway based on the service identifier and input data via the HarmonyOS distributed task scheduling framework; and sending the remote call request to the target gateway via the HarmonyOS distributed soft bus, so that the target gateway executes the current subtask based on the service identifier.

[0050] Specifically, this step clarifies the transformation path from logical decision-making to physical execution. The source gateway first parses the response sequence, extracting the target gateway address, input data slice, and service identifier that uniquely identifies the executable capabilities on the target gateway required for the current subtask. Then, the source gateway calls the standardized interface provided by the HarmonyOS distributed task scheduling framework (such as the StartRemoteAbility interface in the DistributedSched service) to encapsulate the service identifier and input data into a remote call request conforming to the HarmonyOS specification. In this architecture, the HarmonyOS distributed task scheduling framework plays the role of "capability orchestration," shielding the differences between heterogeneous devices and enabling the source gateway to initiate cross-device capability calls as if calling local functions. The HarmonyOS distributed soft bus plays the role of "data transmission," providing a low-latency, highly reliable underlying communication channel for remote call requests, ensuring that requests are accurately delivered to the target gateway. After receiving the request via the soft bus, the target gateway locates and starts the corresponding atomic service or application locally based on the service identifier, and loads the input data to execute the subtask in an independent process sandbox environment. This invocation method, based on HarmonyOS's native capabilities, not only avoids the cumbersome service registration and discovery configurations of traditional RPC solutions but also utilizes system-level security isolation mechanisms to ensure the operational stability of the target gateway. It should be understood that although this embodiment uses the StartRemoteAbility interface as an example, other equivalent interfaces provided by the HarmonyOS distributed task scheduling framework can also be used in other embodiments to achieve remote capability startup, as long as they can achieve cross-device task dispatch and execution based on service identifiers. Through the above mechanism, this application transforms abstract offloading decisions into a standardized, efficient, and secure distributed execution flow, ensuring the reliable delivery of edge computing tasks in dynamic environments.

[0051] Furthermore, the pre-triggering mechanism for task unloading is described in detail. Before selecting at least one candidate gateway that meets the required computing power and latency constraints of each subtask in the subtask list from the real-time updated neighbor resource table, the method further includes: real-time monitoring of the source gateway's running status and the queue of tasks to be processed; the queue of tasks to be processed includes multiple incomplete tasks, each of which includes an estimated computing load and the waiting time; based on the running status and the queue of tasks to be processed, it is determined whether the source gateway meets any of the set of task unloading triggering conditions; if so, the task queue to be unloaded is selected from the queue of tasks to be processed to generate the subtask list.

[0052] Specifically, task unloading does not run unconditionally and continuously, but is driven by specific system status events to avoid unnecessary cross-node communication overhead when the source gateway is under low load. The task monitoring module inside the source gateway continuously collects its own operational status metrics and real-time snapshots of the pending task queue at a preset sampling period (e.g., 1 second). The operational status represents the current resource utilization level of the source gateway, while the pending task queue records all incomplete tasks and their attribute information. The system only activates the subsequent unloading process when monitoring data indicates that the source gateway has encountered a processing capacity bottleneck or a risk to business timeliness. This on-demand triggering mechanism effectively balances the relationship between local computing and distributed collaboration, improving the overall energy efficiency of the system.

[0053] Furthermore, in order to accurately identify the unloading timing, the running status includes CPU utilization; the task unloading trigger condition set includes at least one of the following task unloading trigger conditions: the CPU utilization of multiple consecutive sampling points is greater than the preset CPU utilization threshold; the waiting time of any unfinished task is greater than the preset waiting time; the estimated computational amount of the newly assigned unfinished task is greater than the remaining computable amount of the source gateway.

[0054] Specifically, these three triggering conditions construct a multi-dimensional perception system from three dimensions: continuous processor load, task queuing delay, and sudden computing pressure. As long as any one of these conditions is met, it is determined that task unloading is required.

[0055] Regarding the first condition, namely that the CPU utilization of multiple consecutive sampling points is greater than a preset CPU utilization threshold, the core lies in filtering out transient interference through continuous judgment over time. In real-world edge computing environments, CPU utilization may experience millisecond-level spikes due to brief system interruptions or sudden I / O operations. If offloading is triggered based solely on a single sampling value, it can easily lead to frequent invalid scheduling. Therefore, this embodiment employs a sliding window filtering mechanism, for example, setting the window size to 3. Only when the CPU utilization of the three most recent consecutive sampling points exceeds a preset threshold (e.g., 85%) is the source gateway confirmed to be in a state of continuous computing power strain. This design significantly enhances the robustness of the trigger judgment and avoids false triggering caused by signal jitter.

[0056] Regarding the second condition, namely that the waiting time of any incomplete task exceeds the preset waiting time, the focus is on the Service Level Agreement (SLA) guarantee at the business level. The waiting time refers to the time span from when a task enters the task queue until the current moment. When the waiting time of any task in the queue exceeds the preset time limit (e.g., 200ms), it indicates that the local processing speed can no longer meet the timeliness requirements of that task. At this point, regardless of whether CPU utilization has reached its limit, unloading must be initiated immediately to release the backlog. This condition ensures that high-priority or latency-sensitive tasks are not blocked for extended periods due to available CPU resources, compensating for the shortcomings of purely resource-oriented scheduling.

[0057] The third condition, where the estimated computational load of a newly assigned unfinished task exceeds the remaining computational capacity of the source gateway, is designed to handle sudden surges in large tasks. The remaining computational capacity is a dynamic value, typically calculated by subtracting the currently occupied computational capacity and reserved safety margin from the source gateway's current total computing power. When the estimated computational load of a newly arriving task is excessive (e.g., exceeding 50% of the current remaining schedulable capacity), even if the current CPU utilization is not yet exceeded, forcibly executing it locally could lead to subsequent tasks being starved for extended periods or system responsiveness stalling. By directly including such large tasks in the offloading candidate list, protective isolation of local resources can be achieved, maintaining the stability of the source gateway's basic services.

[0058] When any of the above triggering conditions is met, the source gateway will filter out a queue of tasks to be unloaded from the current queue of pending tasks. The filtering strategy can be full filtering, where all incomplete tasks in the queue are considered as unloadable objects; or it can be priority-based partial filtering, such as selecting only the top N tasks with the longest waiting time or the largest estimated computational load. The filtered queue of tasks to be unloaded will serve as the direct source for generating the input subtask list in subsequent step S101, thus completing the logical connection from state awareness to decision execution. Through this multi-dimensional, filtered triggering mechanism, this application can minimize unnecessary unloading behavior while ensuring business timeliness and system stability, achieving refined and intelligent edge computing resource scheduling.

[0059] Furthermore, the process details how tasks in the task queue to be unloaded are transformed into the subtask list required in step S101. The task queue includes multiple tasks to be unloaded, each containing input data, business priority, and task type. These attributes form the metadata foundation for subsequent fine-grained splitting and resource matching. The input data defines the task's computational object and scale, the business priority reflects the urgency of the task within the distribution area's business system, and the task type determines the computational logic and parallelization potential. By reading these attributes, the source gateway can implement differentiated processing strategies for different tasks, rather than adopting a one-size-fits-all, coarse-grained unloading approach.

[0060] Specifically, the process of generating the subtask list first involves quantifying time constraints. Based on the business priority of any task to be uninstalled in the task queue, the maximum allowable latency for that task is determined. A predefined mapping relationship exists between business priority and the maximum allowable latency. For example, for high-priority tasks involving real-time security control, the maximum allowable latency might be set to within 100ms; while for low-priority tasks such as general trend analysis or statistics, this latency threshold can be relaxed to 500ms or even longer. This mapping mechanism ensures that subsequently generated subtasks inherit the time requirements of the original task, enabling the scheduling system to prioritize the response speed of critical services when resources are scarce, and avoiding timeouts of important tasks due to resource contention.

[0061] After determining the latency constraints, the system needs to evaluate the parallel processing potential of the tasks. Based on the input data, task type, and estimated computational load of each task to be unloaded, it determines whether the corresponding task is a separable task. The criteria for determining a separable task are mainly based on data independence and computational statelessness. If the input data of a task consists of multiple independent data units, and the computation results of each unit are independent of each other, then the task is determined to be a separable task. For example, short-term load forecasting tasks usually require regression analysis of the electricity consumption data of multiple users, and the computation between users is completely decoupled, which is a typical separable task. Conversely, if the task involves global topology analysis or cross-device correlation mining, its computation process strongly depends on the complete dataset and cannot be divided without destroying semantics, then it is determined to be an indivisible task. In this case, the entire task will be treated as a single subtask for processing. This differentiated processing mechanism ensures both the execution efficiency of parallelizable tasks and maintains the semantic integrity of strongly coupled tasks.

[0062] For tasks deemed divisible, the system performs fine-grained partitioning. If a task is divisible, it is divided into multiple independent subtasks based on the amount of input data, and the input data slice and data volume of each subtask are determined according to the input data of the current task. The partitioning strategy can be based on the natural boundaries of the data objects (e.g., by user ID, device number) or a fixed data block size. Each input data slice constitutes an independent computational load for the corresponding subtask, and the subtask data volume characterizes the size of that slice. For example, when processing a multi-user load prediction task with 600 sampling points, the system can split it into 20 subtasks by user dimension, with each subtask corresponding to an input data slice of 30 sampling points. This uniform or semantically aware partitioning based on data volume helps to balance the load among the subtasks and avoids the long-tail effect that drags down the overall completion time.

[0063] After the decomposition is completed, the system needs to complete the full set of attributes required for the execution of each subtask. The required computing power is determined based on the amount of data in each subtask, the latency constraints for each subtask are determined based on the maximum allowable latency of the current task to be unloaded, and a corresponding service identifier is assigned to each subtask based on the task type of the current task to be unloaded, thus generating a subtask list. The required computing power is typically estimated based on historical statistical models or lightweight prediction algorithms, such as the product of the subtask data volume and the unit data processing overhead, in FLOPs or other units of computing power. Latency constraints are directly inherited or proportionally allocated from the maximum allowable latency of the original task, ensuring that subtask-level scheduling remains under the control of the overall business SLA. The service identifier is the link between the subtask and the execution capabilities of the target gateway; it uniquely points to a specific atomic service pre-deployed on the target gateway (such as "LoadForecast_Service_V2"), enabling the HarmonyOS distributed task scheduling framework to accurately locate and launch the correct execution program. The final generated subtask list is a structured dataset, where each item contains complete fields such as subtask ID, input data slice reference, subtask data volume, required computing power, latency constraints, and service identifier. Through the above process, this application transforms macro-level business requirements into micro-level, standardized scheduling units, providing a legitimate, accurate, and complete input source for dual gateway filtering and response sequence generation, thereby fundamentally ensuring the effectiveness and reliability of dynamic offloading of edge computing tasks in distribution substations.

[0064] like Figure 2 As shown, this embodiment provides a computer device, which includes a memory 210 and a processor 220.

[0065] Specifically, memory 210 is configured to store instructions. Instructions here refer to computer program code or data used to implement the aforementioned dynamic offloading method for edge computing tasks in the distribution area. Memory 210 may include high-speed random access memory (RAM) and non-volatile memory (NVM), such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. In actual deployment, memory 210 stores not only the operating system and basic communication protocol stack, but also application modules including neighbor resource table maintenance logic, working condition matching algorithms, response sequence generation rules, and HarmonyOS distributed call interface encapsulation. It should be understood that the specific selection of memory 210 can be flexibly adjusted according to the power consumption, cost, and performance requirements of the edge computing device, as long as it can reliably store and allow the processor to read and execute the required instructions.

[0066] Processor 220 is configured to retrieve instructions from memory 210 and to implement the method when executing instructions. Processor 220 is the core of the computer device's computation and control center. It establishes a communication connection with memory 210 via a system bus or dedicated data path to read instructions and execute corresponding data processing operations. When processor 220 executes instructions stored in memory 210, it drives the computer device to perform a complete offload process, including candidate gateway screening, target gateway selection, response sequence generation, HarmonyOS remote invocation, and result merging. The implementation of processor 220 is not limited to a general-purpose central processing unit (CPU); it can also be a digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. For example, in the distribution area edge gateway scenario where real-time requirements are extremely high, a SoC chip with an integrated AI acceleration unit can be used as the processor 220 to improve the processing efficiency of working condition matching score calculation and task splitting; while in computing power aggregation nodes or regional servers, multi-core high-performance CPU clusters can be used to support the scheduling and management of large-scale concurrent tasks.

[0067] Through the aforementioned hardware architecture, this embodiment solidifies the abstract logical steps in the previous method embodiments into concrete physical entity capabilities. This hardware-software combined implementation ensures, on the one hand, that the dynamic offloading method for edge computing tasks in distribution substations can operate stably on real industrial-grade equipment, meeting the stringent reliability and environmental adaptability requirements of scenarios such as distribution substations; on the other hand, it also provides a clear hardware carrier protection boundary for the technical solution, enabling direct claims against the manufacture, sale, or use of the computer equipment in subsequent intellectual property protection and infringement determination, thereby constructing a comprehensive defense system from method to product. Furthermore, this computer equipment can be deployed as an independent edge gateway in the substation site, or used as a scheduling server in the cloud or regional center, demonstrating broad applicability.

[0068] This embodiment provides a machine-readable storage medium storing instructions that cause a machine to execute the dynamic offloading method for distribution radio area edge computing tasks.

[0069] Specifically, a machine-readable storage medium refers to a physical carrier that can be read by a computer, embedded gateway, or other data processing device to obtain program code or data. In practical applications, this storage medium can take many forms, including but not limited to read-only memory (ROM), random access memory (RAM), optical disc read-only memory (CD-ROM), digital versatile optical disc (DVD), magnetic tape, disk storage devices, flash memory, USB flash drives, SD cards, and any other non-transitory computer-readable media. It should be understood that although various specific media types are listed here, this is only to illustrate the broad applicability of the technical solution of this application and does not constitute a limitation on the specific form of the storage medium. As long as it has the characteristic of storing instructions and being able to be read and executed by a machine, it falls within the protection scope of this application.

[0070] The instructions stored on the medium are a set of compiled or interpreted program code, whose logical structure strictly corresponds to steps S101 to S105 and their preferred embodiments in the aforementioned method examples. When the processor of the edge computing device (such as the source gateway in a distribution network) reads and executes these instructions from the storage medium, the device automatically completes a series of operations, including neighbor resource table maintenance, subtask splitting, dual gateway filtering, response sequence generation, HarmonyOS distributed remote call, and exception handling. In this way, this application transforms the abstract task offloading method into a software product that can be independently distributed, installed, and run. This not only facilitates firmware upgrades or functional deployments on existing edge gateway devices but also provides a standardized software carrier for pre-installation integration on future new devices, thereby constructing a complete intellectual property protection closed loop at the software circulation and product manufacturing levels.

[0071] To more clearly illustrate the operational logic and technical effects of the technical solution of this application in a real-world business environment, the following example demonstrates the technical features of the aforementioned embodiments in a full-link series, using a specific scenario where drastic fluctuations in photovoltaic power within a distribution substation lead to a sudden surge in edge computing load. It should be understood that this application scenario is merely an illustrative example of this application and does not constitute a limitation on the scope of protection of this application. The technical solution of this application can be applied to other edge computing scenarios as long as multi-node collaboration and dynamic task offloading are involved.

[0072] In this scenario, assume that three edge computing devices—Gateway A, Gateway B, and Gateway C—are deployed within the target distribution transformer area, all running the open-source HarmonyOS operating system and with distributed soft bus services enabled. Between 10:00:00 and 10:00:05 on a certain day, due to drastic fluctuations in the distributed photovoltaic power output within the transformer area, Gateway A, as the source gateway, receives 20 short-term load forecasting tasks within a short period. Each task needs to process 15 minutes of historical power data from 6 users, with an estimated computational load of approximately 2 × 10^7 FLOPs. At this time, Gateway A's task monitoring module detects in real-time that its operating status meets the condition that the CPU utilization rate at multiple consecutive sampling points in the task offloading trigger condition set is greater than the preset CPU utilization threshold. Specifically, the CPU utilization rates collected by Gateway A at the three consecutive sampling times of 10:00:03, 10:00:04, and 10:00:05 are 88%, 92%, and 91%, respectively, all exceeding the preset 85% threshold, and confirmed by sliding window filtering to be non-instantaneous jitter. Based on this judgment, Gateway A immediately selects these 20 short-term load prediction tasks from the local pending task queue to form a pending offload task queue, in order to generate a subtask list.

[0073] During the generation of the subtask list, Gateway A determines the maximum allowable latency of 500ms based on the business priority of the tasks to be unloaded, and classifies the batch of tasks as divisible tasks based on the independence of the input data. Subsequently, Gateway A divides each task to be unloaded into independent subtasks according to the user dimension, ultimately forming a subtask list containing 20 subtasks. Each subtask corresponds to a user's load forecasting calculation, carrying the corresponding input data slice (i.e., the user's historical power time series data), subtask data volume, required computing power (approximately 2 × 10^7 FLOPs), latency constraint (500ms), and a load forecasting atomic service identifier used to perform the calculation. Through this fine-grained decomposition, the originally massive batch computing task is transformed into a standardized unit that can be scheduled in parallel, laying the foundation for subsequent accurate resource matching.

[0074] Next, gateway A executes step S101, filtering candidate gateways from the real-time updated neighbor resource table to meet the computing power and latency constraints required for each subtask. A query of the current neighbor resource table shows that gateway B has an idle CPU rate of 75% and an average network RTT of 3ms; gateway C has an idle CPU rate of 30% and an average network RTT of 5ms. Both gateways have sufficient remaining computing power and communication latency to meet the basic requirements of the subtasks, and are therefore listed as candidate gateways. Step S102 is then executed to determine the target gateway based on the operational information of each candidate gateway. Gateway A is substituted into the comprehensive matching score calculation formula, with weighting coefficients w1=0.4, w2=0.2, w3=0.2, and w4=0.2. Calculations show that gateway B, due to its high idle CPU rate, short queue length (currently 2), and fast historical average response time (20ms), has a significantly higher comprehensive matching score than gateway C (currently 8 queue length, historical average response time 50ms). Meanwhile, after load balancing verification, the total computational load of the 20 sub-tasks, 4 × 10^8 FLOPs, did not exceed the 80% safety limit of the remaining computing power of Gateway B (approximately 1.2 × 10^9 FLOPs). Therefore, Gateway A initially determined Gateway B as the target gateway for all 20 sub-tasks.

[0075] After determining the target gateway, gateway A executes steps S103 and S104, generating a response sequence based on the subtask list and the target gateway for each subtask, and accordingly generating remote call requests. The response sequence records the gateway B identifier, input data location, expected return time (set to 300ms), and service identifier for each subtask. Gateway A calls the StartRemoteAbility interface through the HarmonyOS distributed task scheduling framework, encapsulating the service identifier and input data into a remote call request, and concurrently sends these 20 requests to gateway B via the HarmonyOS distributed soft bus. Upon receiving the requests, gateway B starts the load prediction atomic service in an independent process sandbox to perform calculations. Under normal circumstances, the execution time of a single subtask is approximately 15ms; including network and scheduling overhead, the total execution time is far lower than the expected return time.

[0076] However, abnormal situations may occur during actual operation. Suppose that subtask number 15 fails to return a result after the expected return time of 300ms due to local resource contention or momentary interference on gateway B. In this case, gateway A automatically triggers its exception handling mechanism, determining that the subtask has timed out and classifying it as an abnormal subtask. Gateway A then adds this abnormal subtask to the head of its local pending task queue, giving it the highest rescheduling priority, and re-matches it with a target gateway based on the latest neighbor resource table. Since the neighbor resource table shows that gateway B's load has temporarily increased, while gateway C, although having a slightly lower overall score, still has the capacity to handle the load, the system re-identifies gateway C as the new target gateway for this abnormal subtask and initiates a remote call again through the HarmonyOS distributed soft bus. This runtime-triggered dynamic rescheduling mechanism effectively avoids long-term task suspension caused by single-point failures, ensuring the continuity of overall business operations.

[0077] Finally, after gateway A confirms that all 20 subtasks (including the 19 that returned normally and the 15 that returned successfully after rescheduling) have been executed successfully, step S105 is executed to merge the subtask execution results of each subtask to obtain the task output result. In this scenario, the merging operation is manifested as assembling the future 15-minute power prediction curve data points of the 20 users into a complete list of distribution area load prediction results according to the original order in the subtask list. This result can be directly used by the upper-level distribution automation system to smooth out photovoltaic fluctuations or optimize energy storage charging and discharging strategies. As can be seen from the above end-to-end demonstration, when facing sudden loads and runtime anomalies in real business scenarios, the technical solution of this application can achieve dynamic adaptation of edge computing resources and efficient and reliable delivery of tasks through the synergistic effect of mechanisms such as dual screening, fine-grained splitting, HarmonyOS native invocation, and closed-loop anomaly recovery, fully demonstrating the dynamic adaptability and practical value of the solution in the actual environment.

[0078] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for dynamically offloading edge computing tasks in a distribution radio station area, applied to a source gateway, characterized in that, The method includes: At least one candidate gateway is selected from the real-time updated neighbor resource table that meets the required computing power and latency constraints of each subtask in the subtask list; the subtask list stores multiple subtasks of the source gateway's unloaded task. Based on the operating status information of each candidate gateway, determine the target gateway for each subtask; Generate a response sequence based on the subtask list and the target gateway of each subtask; Based on the response sequence, a remote call request is generated for each of the sub-tasks, and the remote call request is sent to the target gateway of the corresponding sub-task through the HarmonyOS distributed task scheduling framework and HarmonyOS distributed soft bus, so that the target gateway executes the corresponding sub-task. If all the subtasks corresponding to the task to be uninstalled are executed successfully, the execution results of each subtask are merged to obtain the task output result.

2. The method according to claim 1, characterized in that, The steps for updating the neighbor resource table include: The device information of multiple edge gateways is received in real time. Based on the device information, a communication connection is established with the multiple edge gateways in the target distribution area through the HarmonyOS distributed soft bus, and the edge gateways are regarded as neighbor gateways. It periodically receives resource status data from neighboring gateways via the HarmonyOS distributed soft bus; The neighbor resource table is dynamically updated based on the resource status data of each neighbor gateway. If no resource status data is received from any of the neighboring gateways and the duration exceeds a preset offline time threshold, then the neighboring gateway is deleted from the neighboring resource table.

3. The method according to claim 2, characterized in that, The operating information includes idle CPU rate, packet loss rate, current queue length, and historical average response time; The step of determining the target gateway for each subtask based on the operational status information of each candidate gateway includes: The overall matching score for each candidate gateway is calculated using the following formula: ;in, This represents the overall matching score corresponding to the i-th candidate gateway; This represents the idle CPU rate of the i-th candidate gateway; This represents the packet loss rate between the source gateway and the i-th candidate gateway; This represents the current queue length of the i-th candidate gateway; This represents the historical average response time of the i-th candidate gateway; , , and These represent the weighting coefficients corresponding to the idle CPU rate, the packet loss rate, the current queue length, and the historical average response time, respectively. The target gateway for each subtask is determined based on the comprehensive matching score, and the total computational load of all subtasks assigned to the same target gateway does not exceed a preset proportion of the remaining computing power of the target gateway.

4. The method according to claim 1, characterized in that, The response sequence includes the expected return time for each of the subtasks; The method further includes: If the expected return time is exceeded and the target gateway of the corresponding subtask does not return the execution result of the subtask, then the execution of the subtask is determined to have timed out, and the subtask is treated as an abnormal subtask. The abnormal subtask is added to the head of the pending task queue of the source gateway, and a target gateway is re-matched for the abnormal subtask based on the neighbor resource table.

5. The method according to claim 4, characterized in that, The step of generating remote call requests for each of the subtasks based on the response sequence, and sending the remote call requests to the target gateway of the corresponding subtask through the HarmonyOS distributed task scheduling framework and HarmonyOS distributed soft bus, includes: Based on the response sequence, determine the target gateway, input data, and service identifier for executing the current subtask corresponding to the current subtask; Using the HarmonyOS distributed task scheduling framework, a remote call request for the current subtask is initiated to the target gateway based on the service identifier and the input data. The remote call request is sent to the target gateway via the HarmonyOS distributed soft bus, so that the target gateway executes the current subtask according to the service identifier.

6. The method according to claim 1, characterized in that, Before selecting at least one candidate gateway from the real-time updated neighbor resource table that satisfies the required computing power and latency constraints of each subtask in the subtask list, the method further includes: The system monitors the running status of the source gateway and the queue of tasks to be processed in real time. The queue of tasks to be processed includes multiple unfinished tasks, and each unfinished task includes an estimated computational load and the waiting time. Based on the running status and the queue of tasks to be processed, determine whether the source gateway satisfies any one of the set of task unloading trigger conditions; If the conditions are met, the unloadable task queue is selected from the pending task queue to generate the subtask list.

7. The method according to claim 6, characterized in that, The operating status includes CPU utilization; The task unloading trigger condition set includes at least one of the following task unloading trigger conditions: The CPU utilization rate of multiple consecutive sampling points is greater than the preset CPU utilization threshold. The waiting time for any of the unfinished tasks is greater than a preset waiting time; The estimated computational load of the newly assigned unfinished task is greater than the remaining computational load of the source gateway.

8. The method according to claim 6, characterized in that, The queue of tasks to be uninstalled includes multiple tasks to be uninstalled, and each task to be uninstalled includes input data, business priority, and task type. The steps for generating the subtask list include: The maximum allowable delay of the task to be uninstalled is determined based on the business priority of any task to be uninstalled in the task queue. Based on the input data, task type, and estimated computational load of each task to be uninstalled, determine whether the corresponding task to be uninstalled is a splittable task. If it is a divisible task, the current task to be uninstalled is divided into multiple independent subtasks according to the amount of input data, and the input data slice and subtask data amount of each subtask are determined according to the input data of the current task to be uninstalled. The required computing power is determined based on the data volume of each subtask, the latency constraint of each subtask is determined based on the maximum allowable latency of the current task to be uninstalled, and a corresponding service identifier is assigned to each subtask based on the task type of the current task to be uninstalled, so as to generate the subtask list.

9. A computer device, characterized in that, include: The memory is configured to store instructions; A processor configured to retrieve the instructions from the memory and, when executing the instructions, to implement the method according to any one of claims 1 to 8.

10. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores instructions for causing the machine to perform the method according to any one of claims 1 to 8.

Images