Distributed bionic flexible scheduling method and system for multi-geographical automation equipment

Abstract

The present application relates to the technical field of distributed computing resource scheduling, and particularly relates to a distributed bionic flexible scheduling method and system for multi-geographical automated equipment. The method divides a target task into micro-batches of bound task domains and intention nodes, constructs a rolling window capacity snapshot based on available slots, execution status, average time consumption and switching loss reported by agent nodes; generates task domain quotas using minimum guarantee, efficiency weighting and idle pool borrowing, and calculates task urgency according to deadlines, quota gaps and waiting aging; after a regional agent node pulls a candidate task, local scoring is performed according to equipment idle degree, fatigue degree, historical running time and portrait affinity, and atomic claiming is performed through execution identification and lease; execution feedback is used to update time consumption mean, output efficiency and fatigue decay parameters. The present application can reduce task domain starvation, equipment overload and cross-regional scheduling conflicts without directly binding specific equipment by the server, and improve heterogeneous equipment resource utilization and task completion rate on time.

Description

Technical Field

[0001] This application relates to the field of distributed computing resource scheduling and automated equipment control technology, specifically to a distributed biomimetic flexible scheduling method and system for multi-regional automated equipment. Background Technology

[0002] In the prior art, there are already technical solutions for distributed task scheduling based on the execution node status and task attributes. For example, Chinese patent application CN111708627A discloses a task scheduling method based on a distributed scheduling framework, in which the master node divides the task to be scheduled into pieces according to the task size, calculates the task load rate of each execution node, and allocates the pieced tasks to the corresponding execution nodes for execution according to the priority of the pieced tasks and the task load rate of each execution node.

[0003] For example, Chinese patent CN109542600B discloses a distributed task scheduling system and method, which completes task scheduling through a task distribution module, a task retrieval module and a task execution module. During the task retrieval process, the available quota of the task set and the task priority weight are used to determine the sub-task instances that can be retrieved, and the priority weight of the corresponding tasks is dynamically adjusted according to the number of sub-task instances that have not yet been retrieved.

[0004] The aforementioned existing technologies can achieve distributed task allocation based on factors such as task priority, execution node load, or available task quota. However, when the scheduling object is further expanded to a large number of heterogeneous automated devices distributed across different regions and managed by regional nodes, if the control server directly binds tasks to devices based on the status of each specific execution device, it needs to continuously obtain the fine-grained operating status of the specific devices. In the case of dynamic changes in device status and delays in cross-regional communication, the device status used by the control server for scheduling may have a time difference from the actual device status.

[0005] Furthermore, in the execution environment of automated equipment, the current idle status, continuous operation level, recovery status, and adaptability to different tasks may vary among different devices. Relying solely on the load of execution nodes or task priorities is insufficient to reflect the current executable capacity of a specific automated device. Additionally, different task domains exhibit differences in minimum completion requirements, historical effective output efficiency, and the remaining task volume within the current time window, making it difficult to continuously adjust static task quotas based on actual execution results.

[0006] Therefore, a distributed scheduling method suitable for heterogeneous automated equipment in multiple regions is needed. Based on the macro-capacity and task resource allocation at the control server, the regional nodes closest to the automated equipment select specific equipment according to the real-time status of the equipment, and continuously adjust the capacity and task resource allocation of subsequent rolling time windows according to the actual task execution time and effective output. Summary of the Invention

[0007] To address the technical issues in existing multi-regional automated equipment scheduling processes, such as the control server's direct selection of specific equipment being highly dependent on the real-time status of the equipment, the difficulty in balancing task completion requirements and resource utilization across different task domains in static resource allocation, inaccurate capacity estimation and equipment selection under dynamic execution conditions, and the potential for duplicate assignment and execution during distributed task assignment, this application provides a distributed biomimetic flexible scheduling method and system for multi-regional automated equipment.

[0008] In a first aspect, this application provides a distributed biomimetic flexible scheduling method for multi-regional automated equipment, comprising:

[0009] The target task is divided into multiple micro-batch tasks with defined execution boundaries, and the micro-batch tasks are associated with task domains and intent nodes.

[0010] Obtain the available execution slots, execution status, average task execution time, and task switching overhead reported by agent nodes in each region, and calculate the capacity snapshot within the rolling time window to determine the number of micro-batch tasks that can be executed within the current rolling time window.

[0011] Based on the capacity snapshot, the task quotas for different task domains are determined using the minimum guarantee, efficiency weighting, and idle pool borrowing methods. The task urgency is calculated based on the task deadline, quota gap, and waiting aging degree. A candidate task queue is formed based on the task urgency.

[0012] The regional agent node obtains candidate tasks from the candidate task queue, scores local automated devices based on their idle time, fatigue level, estimated runtime, profile affinity, and recovery status, and selects automated devices to execute the candidate tasks based on the scoring results.

[0013] The candidate tasks are atomically claimed by executing the identifier and execution lease, so that the regional proxy node that successfully claims the task obtains the execution right of the corresponding task, and controls the validity period of the execution right according to the execution lease;

[0014] Obtain task execution results, update the average task time, task output efficiency, and automation equipment fatigue based on the results, and use the updated data for capacity calculation, task quotas, and equipment selection in subsequent rolling time windows.

[0015] Preferably, the capacity snapshot is determined based on the available execution slots, execution status coefficient, rolling time window length, and safety redundancy coefficient of each regional agent node, and is converted into the number of micro-batch tasks that can be executed within the current rolling time window by combining the average task time and task switching loss.

[0016] Preferably, when allocating task domain quotas, the minimum guaranteed quota is first allocated according to the minimum completion requirements of each task domain, and the remaining capacity is allocated according to the historical task output efficiency. When some task domains cannot use their allocated capacity within the current rolling time window, the corresponding capacity is released to the idle pool and borrowed by other task domains with unfinished tasks.

[0017] Preferably, the fatigue level is a device state quantity that changes over time; when the automated device performs a task, experiences a failure, or a risk event, the fatigue level increases accordingly; during idle or recovery periods, the fatigue level decreases according to a preset attenuation relationship; and the local device score or operating status of the automated device is adjusted based on the fatigue level.

[0018] Preferably, when micro-batch tasks remain unclaimed, the task urgency of the corresponding task is increased based on the waiting time; when the completion rate of multiple consecutive rolling time windows of a task domain is lower than the preset requirement, the scheduling weight of the corresponding task in the task domain is increased to reduce the probability that the task domain cannot obtain execution resources for a long time.

[0019] Preferably, task assignment is controlled by execution identifier, task version, and execution lease; for the same task, only one executor corresponding to a valid execution identifier is allowed to hold the current task execution right, and after the execution lease expires, the late execution result of the original executor is not used to cover the new valid execution status.

[0020] In a second aspect, this application provides a distributed biomimetic flexible scheduling system for multi-regional automated equipment, including a control server, at least one regional agent node, and multiple automated devices connected to the regional agent node.

[0021] The control server is used to perform target task segmentation, rolling time window capacity calculation, task domain quota allocation, candidate task queue construction, and task atomic claiming control; the regional agent node is used to obtain the real-time status of candidate tasks and local automated devices, score local devices based on device idleness, fatigue, estimated runtime, profile affinity, and recovery status, and select automated devices to execute tasks based on the scoring results.

[0022] Compared with the prior art, this application has at least the following beneficial effects:

[0023] (1) By separating the macro-resource allocation of the server from the local device selection of the regional agent node, the control server does not need to continuously specify the specific execution device based on the fine-grained real-time status of cross-regional devices, thereby reducing the impact of cross-regional status transmission delay and device status changes on scheduling decisions.

[0024] (2) By using a rolling time window capacity snapshot, the available execution slots, execution status, average task time and task switching loss of the device are dynamically determined to ensure that the task deployment can change with the actual available execution capacity, thereby reducing the task backlog or idle execution resources caused by static capacity estimation.

[0025] (3) By combining minimum guarantee, efficiency weighting and idle pool borrowing, the task domain quota mechanism ensures that the task domain with minimum completion requirements can obtain the corresponding execution resources, while allowing the temporarily unusable task domain capacity to be used by other task domains, thus taking into account the completion requirements of different task domains and the overall resource utilization rate.

[0026] (4) By incorporating device idleness, fatigue, estimated runtime, profile affinity and recovery status into the local device score of the regional agent node, the specific device selection can be dynamically adjusted according to the current operating status of the device, reducing the probability of the same device executing continuously for a long time and the device in recovery status being assigned tasks again.

[0027] (5) By adjusting the scheduling weight when the task is waiting for aging and the task domain is not completed, the scheduling priority of tasks and task domains that have not obtained execution resources for a long time can be gradually increased, reducing the probability that the task domain cannot obtain execution resources for a long time.

[0028] (6) By controlling the task claiming and execution rights through execution identifiers, task versions and execution leases, and restricting the late results of failed executors from overwriting the current valid execution status, the probability of the same task being executed repeatedly and the execution status being incorrectly overwritten in the case of concurrent claiming, network retries or executor failure is reduced.

[0029] (7) The average task time, task output efficiency and equipment fatigue are continuously updated through task execution feedback, and the updated results are used for capacity calculation, task quota and equipment selection in subsequent rolling time windows, so that the scheduling parameters can be continuously adjusted according to the actual execution results, and the adaptability of the scheduling process of multi-regional heterogeneous automated equipment to the dynamic execution environment is improved. Attached Figure Description

[0030] The above and other objects, features, and advantages of exemplary embodiments of the present invention will become readily apparent upon reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of the invention are illustrated by way of example and not limitation, and like or corresponding reference numerals denote like or corresponding parts, wherein:

[0031] Figure 1 This is a flowchart illustrating a distributed biomimetic flexible scheduling method for multi-regional automated equipment according to the present invention.

[0032] Figure 2 This is a schematic diagram illustrating the two-level architecture of macro-scheduling at the server side and micro-scheduling at the regional proxy nodes in this invention.

[0033] Figure 3 This is a schematic diagram illustrating the rolling window closed-loop diagram of capacity, quota, equipment execution, and feedback updates in this invention. Detailed Implementation

[0034] The term "regional proxy node" as used in this application refers to a computer node deployed in a corresponding regional network environment, communicating with the control server and establishing connections with one or more automated devices within that region. Its functions include obtaining the status of local automated devices, acquiring candidate tasks from the control server, scoring devices based on their real-time status, initiating task claiming requests, and organizing task execution. The regional proxy node can be implemented by software programs running on computers, servers, or edge computing devices.

[0035] The term "task domain" as used in this application refers to a set of tasks formed by dividing tasks to be executed according to business objectives, task types, resource contention scope, or equipment capacity requirements. This set serves as a resource scheduling unit for capacity calculation, task quota allocation, and candidate task organization. A single task domain may include one or more intent nodes.

[0036] The term "intent node" as used in this application refers to a task attribute used to describe the specific content direction of a task to be performed and to establish a matching relationship between the task and the user profile of the automated device. Intent nodes are used for task content classification and profile affinity calculation, and do not represent the tags of the automated device itself.

[0037] The term "micro-batch task" as used in this application refers to a task unit formed by the control server dividing the target to be executed according to the task domain, intent node, resource requirements, planned output and completion deadline, which has a defined execution boundary and can be independently claimed, executed and has its execution results independently fed back.

[0038] The "rolling time window" referred to in this application refers to a scheduling time interval established by the control server according to a set time length and continuously updated according to a set refresh cycle. Within each rolling time window, the control server recalculates the executable capacity and task resource allocation based on the current device status, historical execution data, and tasks to be executed.

[0039] The term "capacity snapshot" as used in this application refers to a data set calculated by the control server based on the availability status, execution factor, historical average execution time, task switching overhead, and safety redundancy coefficient of the automated devices managed by regional agent nodes within the current rolling time window. This data set represents the number of micro-batch tasks that can be committed to be executed within the current rolling time window. Capacity snapshots can be summarized according to automated devices, regional agent nodes, device capacity sets, or task domains.

[0040] The term "device execution factor" as used in this application refers to a numerical parameter that characterizes the degree to which the current operating state of automated equipment affects its executable capabilities. Different device execution factors correspond to different idle, running, or recovery states of automated equipment, and are used for capacity snapshot calculations.

[0041] The "safety redundancy coefficient" referred to in this application is an adjustment parameter used to reserve uncertain capacity caused by network fluctuations, page wait times, device malfunctions, changes in task execution time, and task switching when calculating the executable capacity of the rolling time window.

[0042] The "minimum guaranteed quota" referred to in this application means the minimum task execution capacity reserved for task domains with unfulfilled goals when the current rolling time window capacity is limited. This is to reduce the probability that some task domains will be unable to obtain execution resources for a long time due to historically low execution efficiency or competition from other task domains.

[0043] The term "borrowable idle pool" as used in this application refers to a set of shared capacity that is used to temporarily store releasable capacity that a task domain has acquired but cannot use due to a lack of available equipment, candidate tasks, or necessary execution conditions within the current rolling time window. Other task domains with incomplete tasks can temporarily borrow capacity from this pool according to scheduling rules. The borrowing relationship does not form a fixed capacity occupancy relationship for subsequent rolling time windows.

[0044] The term "task urgency" as used in this application refers to a comprehensive evaluation value used to determine the scheduling priority of micro-batch tasks in the candidate task queue, which is determined based on at least one or more of the following: task deadline, task domain quota gap, task waiting time, task priority, and risk factors.

[0045] The term "waiting aging" as used in this application refers to a scheduling mechanism that increases the urgency of micro-batch tasks as the waiting time or the number of consecutive rolling time windows increases when the tasks are not continuously claimed or do not obtain execution resources.

[0046] The term "equipment fatigue" as used in this application refers to a quantity representing the cumulative operating load or risk level of automated equipment caused by continuous operation, task execution, task failure, risk events, and abnormal states, and which can decrease with idle time or recovery time according to a preset decay relationship. Equipment fatigue is used for equipment state switching and local equipment scoring of regional agent nodes.

[0047] The term "profile affinity" as used in this application refers to the degree of fit calculated based on the matching relationship between the user profile bound to the automated device and the task domain or intent node corresponding to the micro-batch task, which is used by the regional agent node to select an automated device suitable for executing the corresponding micro-batch task.

[0048] The “device compatibility score” or “local device score” referred to in this application refers to the comprehensive compatibility evaluation result between the device and the task calculated by the regional agent node for the candidate task and the available automated devices in the local area, based on the device idle time, device fatigue, expected runtime, profile affinity, recovery status and task-related parameters, and is used to select the automated device to execute the candidate task.

[0049] The term "execution identifier" as used in this application refers to information generated or obtained by a regional proxy node during the process of claiming and executing a micro-batch task, used to uniquely identify the execution instance of that task. The control server identifies the executor with task execution rights based on the currently valid execution identifier, and uses the execution identifier to distinguish different claiming or retrying processes of the same task.

[0050] The term "execution lease" as used in this application refers to the task execution right granted by the control server to the corresponding executor after a micro-batch task is successfully claimed, which has a valid period. The execution lease can be renewed according to the set rules within its validity period; after the execution lease expires, the control server can determine whether to continue waiting, re-enter the queue, or generate a compensation task based on the task execution status and execution checkpoints.

[0051] The term "atomic assignment" as used in this application refers to the process by which the control server, after verifying the current state, task version, and existing execution rights of a micro-batch task, determines the task execution rights through an indivisible state update operation, ensuring that only one executor corresponding to a valid execution identifier exists for the same micro-batch task at any given time. The indivisible state update operation can be implemented through database transactions, conditional updates, comparison exchanges, atomic scripts, or other methods with equivalent atomicity.

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

[0053]

Example 1

[0054] This invention discloses a distributed biomimetic flexible scheduling method and system for multi-regional automated equipment, referring to... Figure 1 The method is implemented according to the following steps.

[0055] S1. Intended segmentation and micro-batch construction of target tasks.

[0056] In an optional embodiment, the control server receives a target to be executed. The target includes at least a task domain, intent node, planned output, completion deadline, permitted geographical area, device capability requirements, and risk constraints. The task domain is used to distinguish resource contention boundaries, and the intent node describes the association between the task content and the device user profile, no longer relying on ambiguous account tags.

[0057] The control server divides the target into multiple micro-batch tasks that can be independently claimed, executed, and settled. Each micro-batch task preferably corresponds to an estimated workload of 15 to 25 minutes, but can also be dynamically determined based on the task type. Each micro-batch task records the task identifier, task domain, intent node, estimated execution duration, switching overhead, deadline, priority, capacity constraints, maximum number of retries, and checkpoint strategy.

[0058] The estimated execution time is not a fixed constant, but is calculated based on historical execution times for the same task type, equipment capability group, or region. For new task types lacking historical samples, the median of tasks within the same capability group is used as the group prior; as the sample size increases, an exponential moving average is used for updates. This allows micro-batch granularity and cost estimation to converge with actual execution performance.

[0059] Before micro-batch tasks enter the scheduling state, resource feasibility is checked. When there are no regional agent nodes or device groups that meet the capacity constraints, the task is marked as resource blocked and a reason code is generated, instead of continuously entering the normal candidate queue and occupying sorting space.

[0060] S2, Scrolling window capacity snapshot and safety redundancy calculation.

[0061] In an optional embodiment, each regional agent node periodically reports a device status summary. The device status includes at least idle, running, recovered, offline, and isolated states; it also includes device capacity, recent task type, continuous runtime, risk status, network quality, and availability period. The server uses a rolling window of one to two hours and refreshes capacity snapshots every fifteen to thirty minutes.

[0062] For device d and task type k, the formula for calculating the number of micro-batches C(d,k,t) is C(d,k,t)=ρ×A×X×W / (Tavg+Tswitch).

[0063] In the formula, W is the length of the current rolling time window in minutes; in an optional embodiment, W is 60-120 minutes and recalculated according to a refresh cycle of 15-30 minutes; A is the device availability indicator value, used to indicate whether the device has the basic conditions to execute the corresponding task type k within the current rolling time window; when the device is online, not isolated, and meets the device capabilities required by the task, A is 1, otherwise A is 0; X is the device execution factor, used to indicate the impact of the device's current operating state on its executable capability; X is 1 when the device is idle, 0 when it is running, and a value greater than 0 and less than 1 when it is in recovery state; in an optional embodiment, X is 0.5 in recovery state and can be adjusted according to the recovery progress. ρ is the safety redundancy coefficient, used to reserve uncertain capacity caused by network fluctuations, page wait times, device anomalies, and task execution time fluctuations; in an optional embodiment, ρ is taken as 0.65 to 0.70, and adjusted according to the task timeout rate and device idle rate of the aforementioned rolling time window; Tavg is the historical average execution time corresponding to the capability group of device d and task type k, in minutes; this value is calculated based on the actual execution time of completed tasks and updated with new execution results; Tswitch is the expected task switching loss when executing the aforementioned task, in minutes, including the switching time generated between the end of the previous task and the entry of the next micro-batch task into the effective execution state, and is determined based on historical task switching data.

[0064] When the calculated C(d,k,t) is not an integer, an integer value not exceeding the calculated result can be taken according to the capacity allocation strategy as the number of micro-batches that can be committed to be executed within the current rolling time window.

[0065] In one example, the rolling time window W is 120 minutes, device d is idle and meets the device capability requirements of task type k, therefore A=1, X=1; the safety redundancy coefficient ρ is 0.70; the historical average execution time Tavg for this task type is 15 minutes, and the average task switching loss Tswitch is 2 minutes, then:

[0066] C(d,k,t)=0.70×1×1×120 / (15+2)≈4.94.

[0067] Therefore, the device can commit to executing 4 micro-batch tasks within the current rolling time window.

[0068] The security redundancy coefficient is used to absorb uncertainties caused by network fluctuations, page wait times, device malfunctions, and task switching. The server can dynamically adjust ρ based on the timeout ratios of recent windows: when the timeout ratio increases, the promised capacity is reduced; when the device idle ratio remains high, ρ is increased within the upper limit. The capacity of each device is aggregated according to capacity constraints into the regional proxy node capacity, and further aggregated into the available capacity of the task domain.

[0069] When a local proxy node reports an interruption, the server does not immediately release all of its capacity to new tasks. Instead, it calculates the short-term reserved capacity and the reallocatable capacity based on the connection lease and the task execution lease, respectively, to avoid frequent migration of tasks between multiple regions due to short-term network jitter.

[0070] S3, minimum guarantee, efficiency weighting, and task domain quotas borrowed from the idle pool.

[0071] In an optional embodiment, the server first calculates the basic requirements based on the planned output, remaining time, historical effective output rate, and historical average time consumption for each task domain. The historical effective output rate represents the probability of obtaining a valid result or the number of valid outputs per unit time when completing a micro-batch. The basic requirements can be obtained by dividing the remaining target quantity by the historical effective output rate and the average output per batch.

[0072] When total demand does not exceed the capacity snapshot, the server can meet the needs of each task domain and reserve safe idle capacity. When total demand exceeds the capacity snapshot, a minimum guaranteed quota is first allocated to each task domain. The minimum guaranteed quota can be determined by the task domain's minimum completion requirement, deadline, and number of consecutive incomplete windows. The remaining capacity is then allocated according to the normalized weights of the task domain's historical efficiency, deadline pressure, quota gap, and risk coefficient.

[0073] If a task domain has been allocated a quota but lacks available equipment, candidate tasks, or necessary external conditions within the current window, it can release its capacity into the idle pool. Other task domains can borrow capacity from the idle pool without encroaching on the original task domain's minimum guarantee. Borrowing is only valid within the current scrolling window; it is recalculated in the next window, thus avoiding long-term fixed resource occupancy relationships.

[0074] If the completion rate of a task domain falls below the threshold for multiple consecutive windows, the rescue coefficient for that task domain is increased, and some idle pool capacity is reserved. The rescue coefficient increases with the number of consecutive insufficient windows and gradually decreases after the completion rate of the task domain recovers. This avoids long-term starvation of the task domain and prevents a short-term anomaly from permanently increasing its priority.

[0075] S4, candidate queue, task urgency, and waiting aging.

[0076] In an optional embodiment, each task domain maintains its own candidate queue. The urgency U of a micro-batch task consists of a deadline item, a quota gap item, a waiting aging item, a task priority item, and a risk deduction item. The closer the deadline, the larger the remaining quota gap in the task domain, and the more task waiting windows there are, the higher the urgency; the higher the risk or the more unstable the resource conditions, the greater the risk deduction.

[0077] The candidate queue can be implemented using an ordered set sorted by urgency. Instead of directly binding the head task to a specific device, the server returns Top-N candidate tasks based on the executable task domains, capability sets, and current capacity of the regional proxy nodes. The number of candidates, N, is dynamically adjusted based on the number of available devices at the regional proxy nodes, network round-trip latency, and the failure rate of task claiming.

[0078] The aging count is incremented by a scrolling window, rather than solely by absolute creation time. If a task is skipped by a regional proxy node due to capability mismatch, it is not counted as a failed claim by that proxy node, but the task continues to age globally. When the aging value exceeds the rescue threshold, the allowed regions can be expanded or non-critical capability constraints can be reduced, but hard security constraints must not be exceeded.

[0079] By using independent queues for task domains and cross-queue candidate extraction, we can avoid a single high-traffic task domain from occupying the top of the global queue for a long time. At the same time, we can provide multiple optional tasks for regional agent nodes, reducing idle time caused by mismatch between the top task and the local device.

[0080] S5, Local Device Scoring and Atomic Claiming of Regional Agent Nodes.

[0081] In an optional embodiment, after receiving the candidate task set, the regional agent node selects a device based on its local real-time status. A fit score S(d,j) is calculated for candidate task j and device d. The fit score can be represented as: a positive weighted term for idle time minus negative weighted terms for fatigue and expected runtime, plus the affinity between user profile and intent node, task priority, and a small random perturbation. The random perturbation is only used to break identical scores, and its magnitude is limited to a range that does not change the obvious superiority / inferiority relationship.

[0082] Equipment fatigue level F is composed of historical values ​​decaying over time and risk event increments. For example, the historical fatigue value after time Δt decays by F0 × 2^(-Δt / h), where h is the half-life; a successful task increases the value slightly, while consecutive timeouts, minor risks, major risks, and abnormal restarts increase it significantly. When the fatigue level exceeds the pause threshold, the equipment enters a recovery state; once it drops to the recovery threshold, it enters an idle state.

[0083] Affinity is calculated based on the user profile and task intent node bound to the device. The user profile may include allowed task domains, historical successful task types, active periods, device capabilities, and recent risk status. When there are no individual samples for a new device, the success rate of a group of devices with similar capabilities is used as the group prior. As the number of individual samples increases, it smoothly switches to individual statistical values.

[0084] After selecting the task and device combination, the regional agent node sends an atomic claim request to the server. The claim request includes the task identifier, task version, device identifier, execution identifier, and lease term. The server atomically writes the execution information as long as the task is still claimable, the version is consistent, and the device is not occupied by other valid executions. Subsequent statuses and results must carry the current execution identifier; late reports from the old executor cannot overwrite the new execution status.

[0085] S6, Execution state machine, feedback update and closed-loop correction.

[0086] In an optional embodiment, the execution status of a micro-batch task includes at least the following states: pending scheduling, claimed, running, waiting for recovery, successful, failed, canceled, and resource blocked. Device status includes at least the following states: idle, running, and recovered. Execution checkpoints are recorded before the task begins, and during execution, stages, elapsed time, effective output, and risk events are periodically reported, and the execution lease is renewed.

[0087] When a local proxy node experiences a brief disconnection but its execution lease has not yet expired, the server places the task in a recovery waiting state and does not immediately reassign it. After the proxy recovers, it can carry the same execution identifier to continue transmitting the checkpoint. After the execution lease expires, the server decides whether to re-enqueue the task, generate a compensation task, or transfer it to manual processing based on whether the task has external side effects, the last checkpoint, and the current verifiable status of the device.

[0088] After a task is completed, the actual time taken is used to update the average execution time for the corresponding task type and device capability group. The average execution time (Tnew) can be determined using the formula Tnew=η×Tactual+(1-η)×Told.

[0089] Wherein, Tnew is the average execution time obtained after the update upon completion of this task; Tactual is the actual execution time of this task from entering the effective execution state to the end of execution; Told is the average execution time of the corresponding task type and device capability group saved before this update; η is the update weight coefficient, with a value greater than 0 and less than or equal to 1, used to determine the degree of influence of the actual execution time on the average execution time after the update. Tnew, Tactual, and Told use the same time unit.

[0090] η can be preset or dynamically adjusted based on the number of historical samples or the freshness of historical data. A larger η can be set when the number of historical samples is small or when it is necessary to increase the impact of recent execution results; a smaller η can be set when the number of historical samples is large and the execution time is relatively stable. In an optional embodiment, η is set to 0.3, meaning the actual execution time accounts for 30% of the updated result, and the original average execution time accounts for 70% of the updated result.

[0091] For example, if the average execution time (Told) for a certain task type and device capability group before the current task execution was 15 minutes, and the actual execution time (Tactual) for the current task was 18 minutes, and η is taken as 0.3, then the updated average execution time is:

[0092] Tnew = 0.3 × 18 + 0.7 × 15 = 15.9 minutes.

[0093] The updated Tnew is used as the new average execution time for this task type and device capability group, and is used for capacity snapshot calculation in subsequent rolling time windows.

[0094] In addition, the output efficiency E of the corresponding task domain is updated based on the effective output quantity and actual execution time in the task execution results; the corresponding risk status is updated based on the failure type generated during task execution; the equipment fatigue is updated based on whether the automated equipment executes successfully, fails, or experiences a risk event, and the updated results are used for subsequent task quota calculations and local equipment scoring.

[0095] The server recalculates the capacity snapshot and task domain quotas in the next scrolling window. If the device idle rate is high but tasks are not completed in the previous window, it indicates that the candidate matching or quota constraints are too strict, and the number of candidates can be increased or the idle pool can be released; if the timeout rate is high, the safety redundancy coefficient can be reduced or the estimated time can be increased. Through continuous feedback, the system can adapt to changes in device performance, network, and task costs.

[0096]

Example 2

[0097] Reference Figure 2 This invention provides a distributed biomimetic flexible scheduling system for multi-regional automated equipment. The system includes a control server, at least one regional agent node, and at least one automated device managed by each regional agent node. The control server establishes communication connections with each regional agent node, and each regional agent node establishes communication or control relationships with the automated devices it manages, thereby forming a two-level scheduling structure in which the control server performs global scheduling and the regional agent nodes perform local device selection and task organization.

[0098] like Figure 2As shown, the control server serves as the global scheduling layer, including a micro-batch generator, a rolling capacity calculator, a task domain quota generator, a candidate queue, an atomic claim service, a feedback aggregator, and a task and state storage module.

[0099] The micro-batch generator receives the targets to be executed and, based on information such as task domain, intent node, planned output, resource requirements, completion deadline, and estimated execution cost, divides the targets into micro-batch tasks that can be independently claimed and executed. The generated micro-batch tasks are written to the task and state storage module and serve as the basis for subsequent capacity allocation and candidate task organization.

[0100] The rolling capacity calculator communicates with the task and status storage module and regional agent nodes to obtain information such as available slots, execution factors, historical average execution time, task switching losses, and risk status reported by each regional agent node. It then calculates the number of executable micro-batches corresponding to each automated device or set of device capabilities based on the current rolling time window, and further summarizes this to obtain a capacity snapshot for the current rolling time window. This capacity snapshot represents the number of micro-batch tasks the system can commit to executing within the current time window.

[0101] The task domain quota allocates capacity to task domains with incomplete tasks based on a capacity snapshot obtained from the rolling capacity calculator. The task domain quota allocates a minimum guaranteed quota to each task domain first, and then allocates remaining capacity based on factors such as the task domain's historical effective output efficiency, deadline pressure, and the amount of incomplete tasks. When a task domain lacks executable devices, candidate tasks, or other necessary execution conditions within the current rolling time window, its unusable non-guaranteed capacity can be released to the available idle pool for temporary use by other task domains with incomplete tasks.

[0102] The candidate queue is used to store micro-batch tasks that are allowed to be acquired and claimed by regional proxy nodes within the current rolling time window. The control server calculates the task urgency based on factors such as task deadline, task domain quota shortfall, task aging, task priority, and task domain rescue coefficient, and organizes the candidate task queue according to the task urgency, so that tasks that are close to the deadline, have insufficient quota, or have long waiting time have a higher scheduling opportunity.

[0103] like Figure 2 As shown, each regional agent node serves as a local execution layer and may include a local scheduler, a device status repository, a fatigue calculator, a profile affinity calculator, a task executor, and a process monitor.

[0104] The device status repository stores the current operating status of automated devices managed by local domain agent nodes, including device availability, current task status, cumulative runtime, recovery status, and status information related to device execution capabilities. The fatigue calculator calculates device fatigue based on continuous operation, task execution, task failure, risk events, and recovery time. The profile affinity calculator calculates profile affinity based on the matching relationship between the user profile bound to the automated device and the corresponding task domain or intent node of the candidate task.

[0105] After the local scheduler obtains the currently allowed candidate tasks and corresponding quota information from the candidate queue of the control server, it does not directly specify the device according to the order of the candidate queue. Instead, it reads the information provided by the device status warehouse, fatigue calculator and profile affinity calculator, scores the available automation devices in the local domain based on factors such as device idleness, device fatigue, expected runtime, profile affinity and recovery status, and selects the automation device that is suitable for the current candidate task.

[0106] After selecting automated equipment, the regional agent node initiates a task claiming request to the atomic claiming service of the control server. The claiming request carries at least the task information to be claimed and an execution identifier to identify this execution instance. The atomic claiming service verifies the task's current status, task version, and existing execution rights, and determines the task execution rights through atomic status updates, ensuring that each micro-batch task corresponds to only one valid executor at any given time. Upon successful claiming, the control server records the corresponding execution identifier and task execution lease, and sends the claiming result back to the regional agent node.

[0107] After a regional agent node obtains task execution rights, the task executor organizes selected automated devices to execute the corresponding micro-batch tasks. For tasks that require access to browsers, applications, or other device control capabilities, the task executor can drive the automated devices to complete the operation through the corresponding device control interface. The process monitor is used to monitor the running status of relevant task execution processes or device control processes, and provides abnormal status information to the local scheduler when a process exits abnormally or an execution error occurs.

[0108] During task execution, the regional proxy node reports execution heartbeats, progress, or checkpoints to the control server according to preset rules, and renews the task execution lease when the renewal conditions are met. If a regional proxy node experiences a brief disconnection, the control server can retain the execution rights of the corresponding task for the lease's validity period; when the lease expires, the control server determines, based on the obtained execution checkpoints and task status, whether to continue waiting for the original executor to recover, add the task back to the candidate queue, generate a compensation task, or transfer it to manual processing.

[0109] After task execution, the regional agent node feeds back the task execution results to the feedback aggregator on the control server. Feedback information may include actual execution time, effective output quantity, failure type, risk events, and equipment operating status. The feedback aggregator writes the execution feedback into the task and status storage module and uses it to update the historical average execution time, effective output efficiency of the task domain, risk parameters, and equipment fatigue-related data for the corresponding task type and equipment capability set.

[0110] The updated historical average execution time, effective output efficiency, risk status, and equipment status are further used as inputs for the next rolling time window capacity calculation, task domain quota allocation, task urgency calculation, and local equipment scoring, thus forming a closed-loop scheduling process of "task generation - capacity calculation - quota allocation - candidate task organization - local equipment selection - atomic claiming - task execution - execution feedback - parameter update".

[0111] In the aforementioned two-tier scheduling structure, the control server is primarily responsible for macro-level resource coordination across geographical regions, without needing to directly specify the specific automated equipment to execute the task during each task scheduling. Regional proxy nodes utilize their timely access to local region equipment status to select the appropriate equipment. Thus, even with dynamic changes in the number of automated devices, their status, task execution time, and task output efficiency, the control server can continuously adjust task supply and task domain quotas based on a rolling time window, while regional proxy nodes can adjust specific equipment selection based on real-time equipment status, thereby reducing the impact of cross-regional equipment status changes on global scheduling decisions.

[0112]

Example 3

[0113] Reference Figure 3 This embodiment exemplifies the interactive process of task scheduling, task assignment, task execution, execution feedback, and the next round of scheduling between the control server, regional agent nodes, automated devices, and device actuators.

[0114] First, the regional agent node obtains the operating status of the automated equipment it manages and reports the equipment capacity and status information to the control server. This capacity and status information includes available slots, equipment execution factor, historical average execution time, risk status, and other information used for rolling time window capacity calculation. Upon receiving this information, the control server calculates the capacity snapshot of the current rolling time window using the rolling capacity calculator and, in conjunction with information such as current pending tasks, minimum guaranteed quota for the task domain, historical effective output efficiency, and deadline pressure, completes task resource allocation.

[0115] The control server constructs a candidate task queue based on the task resource allocation results of the current rolling time window and provides the candidate tasks and corresponding quota information to the regional agent nodes. After obtaining the candidate tasks, the regional agent nodes use the local scheduler to read the real-time status of the automated equipment they manage, and perform local scoring on the available automated equipment based on equipment idleness, fatigue level, estimated runtime, profile affinity, and recovery status, selecting the automated equipment that matches the candidate task.

[0116] After selecting local devices, the regional proxy node initiates a claim request for the corresponding micro-batch task to the control server. The control server's atomic claim service verifies the task's current status, version, and existing execution rights, and determines the task execution rights through atomic status updates. Upon successful claim, the control server records the execution identifier and task execution lease corresponding to this task and sends the claim result back to the regional proxy node.

[0117] After obtaining task execution rights, the regional proxy node issues a task execution instruction to the selected automated device. This instruction carries an execution identifier corresponding to the current task. The automated device then invokes the appropriate device executor to complete the specific operation based on the task type. This device executor can be a browser executable, an application execution module, or another task execution program that establishes a control relationship with the automated device.

[0118] During task execution, the automated equipment and the equipment actuator perform driving operations and collect execution data. The equipment actuator feeds back the execution telemetry information and stage execution results to the automated equipment, and the automated equipment or regional agent node generates corresponding execution status information.

[0119] During task execution, the regional proxy node reports execution telemetry information, stage execution results, and execution lease renewal requests to the control server. The control server processes the execution information and renewal requests based on the current execution identifier, task status, and lease status, ensuring that the task continues to be executed by the current executor during the valid lease period.

[0120] Upon completion of the task, the regional agent node will report the final execution result and execution telemetry information to the control server. The final execution result may include one or more of the following: whether the task was completed, the actual execution time, the number of effective outputs, the type of failure, and risk events.

[0121] After receiving the execution result, the feedback aggregator on the control server writes the result to the task and state storage module and updates subsequent scheduling parameters based on the actual execution data. Specifically, it updates the historical average execution time Tavg for the corresponding task type and equipment capability set based on the actual execution duration; it updates the effective output efficiency E of the task domain based on the effective output quantity and the actual execution duration; it updates risk parameters based on task failures or risk events; and it updates equipment fatigue based on equipment operation and recovery status.

[0122] After updating the above parameters, the control server re-acquires the device capabilities and status information of each regional agent node in the next rolling time window, and recalculates the capacity snapshot and task resource allocation using the updated historical average execution time, effective output efficiency, risk status, device fatigue, and current remaining tasks, thus entering the next round of scheduling.

Claims

1. A distributed biomimetic flexible scheduling method for multi-regional automated equipment, characterized in that, include: The target to be executed is divided into multiple independently executable micro-batch tasks according to the task domain, intent node, resource requirements, planned output, and completion deadline. For each micro-batch task, the expected execution time, switching loss, and set of allowed device capabilities are recorded. Receive device available slots, device execution status, device recovery status, historical average execution time, task switching loss and risk status reported by multiple regional agent nodes, and construct capacity snapshots of each regional agent node and each task domain based on rolling time windows and security redundancy coefficients. Based on the capacity snapshot, first allocate the minimum guaranteed quota to each task domain, then allocate the remaining capacity according to the historical output efficiency of each task domain, and write the unoccupied capacity into the available free pool. The task urgency is calculated based on the task deadline, task domain quota gap, task waiting time, and task priority, and the micro-batch tasks are written into the candidate queue of the corresponding task domain. The regional proxy node pulls multiple candidate tasks from the candidate queue of at least one task domain. For each candidate task and available devices in the local domain, the device adaptation score is calculated based on device idleness, device fatigue, expected runtime, affinity between device profile and intent node, recovery status, and random disturbances. The target device is selected based on the device compatibility score. The task execution lease is obtained atomically through the claim request containing the execution identifier, device identifier, task identifier and validity period, so that the same micro-batch task is occupied by only one valid execution identifier at the same time. Collect task execution status, actual time consumption, effective output, failure type and equipment risk events, update average execution time, task domain output efficiency and equipment fatigue, and adjust task domain quota, task urgency and equipment adaptation score in subsequent rolling time windows.

2. The method according to claim 1, characterized in that, The capacity snapshot is determined based on the following calculation method: For each device, the time window length is multiplied by the device availability status, device execution factor and safety redundancy coefficient, and then divided by the sum of the historical average execution time and task switching loss for the corresponding task type to obtain the number of executable micro-batches for that device in the current rolling time window. The device execution factor takes a first value when the device is idle, zero when the device is running, and a second value that is greater than zero and less than the first value when the device recovers. The agent capacity is obtained by summing the number of executable micro-batches of each device under the same regional agent node, and then mapping it to the corresponding task domain capacity according to the device capacity set.

3. The method according to claim 1, characterized in that, The generation of the task domain quota includes: The basic requirement is calculated based on the planned output of the task domain, the historical effective output rate, and the historical average execution time. When capacity is insufficient, the minimum guaranteed amount for each task domain is prioritized, and the remaining capacity is allocated according to the normalized weights of historical output efficiency, deadline pressure and quota gap. When a task domain cannot use its allocated capacity within the current window, the free capacity is written to the available free pool, allowing other task domains to temporarily borrow it without falling below the minimum guaranteed amount.

4. The method according to claim 1, characterized in that, The task urgency level includes at least the deadline, quota gap, aging-out waiting items, task priority, and risk deduction items. The waiting aging item increases monotonically with the number of scrolling windows where micro-batch tasks are continuously unclaimed. When the completion rate of multiple consecutive scrolling windows in the same task domain is lower than a set threshold, the rescue coefficient of the task domain is increased, and capacity is reserved from the available idle pool to reduce resource scheduling starvation at the task domain level.

5. The method according to claim 1, characterized in that, The equipment fatigue is calculated based on a time decay term and a risk event increment term. The time decay term causes the equipment fatigue to decrease with idle or recovery time by a set half-life; The risk event increment item increases fatigue values ​​differently based on continuous operation, task failure, mild risk, severe risk, and abnormal restart; When the equipment fatigue level exceeds the pause threshold, the equipment will be switched to recovery mode and will rejoin the equipment scoring once the fatigue level drops to the recovery threshold.

6. The method according to claim 1, characterized in that, The affinity is calculated from the user profile bound to the target device and the intent node of the micro-batch task. The user profile includes at least the device's allowed task domain, historical successful task types, active time periods, and device capability characteristics. When no user profile samples exist, the historical success rate of a group of devices with similar capabilities is used as the group prior. As the target device samples increase, the group prior is smoothly replaced with the target device posterior data.

7. The method according to claim 1, characterized in that, The atomic acquisition task execution lease includes: While the task is still in an claimable state, the target device is still in an available state, and the version number in the claim request is equal to the current task version number, the execution identifier, target device identifier, lease expiration time, and task status are atomically written. During task execution, only status reports and result reports carrying the current execution identifier are accepted; When the lease expires and no renewal is received, the task will be transferred to the recovery judgment state. Based on the reported checkpoints, the task will be re-entered into the team, continue to wait for the original executor to recover, or generate a compensation task.

8. A distributed biomimetic flexible scheduling system for multi-regional automated equipment, characterized in that, This includes a control server, multiple regional agent nodes, and multiple automated devices; The control server includes a micro-batch generation module, a capacity snapshot module, a task domain quota module, a candidate queue module, an atomic claim module, and a feedback update module. The regional agent node includes a candidate task retrieval module, a device status module, a fatigue module, an affinity calculation module, a local device scoring module, and a task execution state machine module; The system is configured to perform the method of any one of claims 1 to 7.

9. An electronic device comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images