Industrial robot cluster distributed data scheduling and load balancing method

Abstract

The application is a kind of industrial robot cluster distributed data scheduling and load balancing method, belonging to the field of industrial internet and edge computing technology. First, the method is based on the three-layer collaborative architecture of "cloud-edge-end". In the bidirectional ring network composed of multiple industrial computers, each node runs a distributed scheduling algorithm, sets weights according to different business types, and combines local queue backlog, neighbor node state and hop count information to the cloud exit to calculate the weighted total pressure difference facing the neighbor nodes, to drive the adaptive transmission of data in the network. Second, by constructing a target function based on Lyapunov optimization, the optimal decision is selected from the candidate actions of local processing and transmission in different directions, realizing the differentiated scheduling of multi-priority services and network load balancing. The application can improve the data transmission efficiency and reduce the transmission delay of high-priority services without changing the existing industrial switch hardware.

Description

Technical Field

[0001] This invention relates to the field of industrial internet and edge computing technology, and in particular to a method for distributed data scheduling and load balancing of industrial robot clusters. Background Technology

[0002] With the widespread application of industrial robot clusters in discrete manufacturing scenarios such as automotive welding and 3C electronics assembly, the volume of sensor data, control commands, and video streams is exploding. Existing industrial data acquisition mostly adopts a centralized architecture of "single machine-gateway-cloud," which has prominent bottlenecks in large-scale collaborative operations: high-concurrency bursts of traffic can easily saturate gateway bandwidth, causing buffer overflows and data packet loss; the load on workshop workstations is uneven in time and space, with some nodes congested while some links are idle, and traditional static routing cannot dynamically alleviate congestion.

[0003] Robot data includes multiple priorities such as control commands, AI inference, and log backups, with significantly different QoS requirements. Traditional first-in-first-out (FIFO) mechanisms can easily lead to cold data blocking high-priority hot data, causing control commands to time out. Although industrial ring networks provide link redundancy, traditional protection protocols only support link-level switching and lack dynamic traffic sharing capabilities. After a failure, secondary congestion can easily occur, and the self-healing time cannot meet the millisecond-level requirements.

[0004] Existing cloud-edge-device scheduling solutions often focus only on the load of computing nodes, neglecting the real-time status of network links. This makes it difficult to provide differentiated services based on service type, and data is prone to ineffective routing within the network, failing to achieve global load balancing. Therefore, existing technologies cannot simultaneously meet the requirements of high-concurrency transmission, multi-service QoS guarantees, dynamic load balancing, and rapid self-healing, making them unsuitable for the efficient and stable operation of industrial robot clusters. Summary of the Invention

[0005] This invention primarily addresses the aforementioned problems by providing a distributed data scheduling and load balancing method for industrial robot clusters. The method calculates the weighted total pressure difference towards neighboring nodes based on the backlog of local service queues, the weighted backlog of neighboring nodes, and the number of hops to the cloud egress. Then, based on a Lyapunov optimization objective function, it selects the optimal action from local processing, leftward transmission, rightward transmission, and their combinations to achieve differentiated transmission of multi-priority services and ring network load balancing.

[0006] The technical solution adopted by this invention to solve its technical problem is a distributed data scheduling and load balancing method for industrial robot clusters, comprising the following steps: S1: Establish and initialize a three-layer collaborative architecture including the edge, cloud, and terminal sides; the edge side consists of an industrial robot cluster, responsible for collecting raw data and uploading it to the terminal side; the terminal side is a bidirectional ring network of multiple industrial computers and industrial exchange mechanisms, with each industrial computer serving as a computing node and each computing node having two neighbor nodes; the cloud side receives the data uploaded by the terminal side for long-term storage, analysis, and model training. S2: The computing node receives data, classifies the received data, and maps it to the tail of the corresponding virtual sub-queue; S3: For each computing node, read the status information of the current time slot; S4: Each computing node exchanges status information with its neighboring nodes and calculates the weighted total pressure difference with its neighboring nodes. The weighted total pressure difference is obtained based on the sum of various data accumulation differences between adjacent computing nodes and the difference in the shortest path hop count between the target node. S5: Establish action constraints for each computing node and enumerate candidate actions that satisfy the action constraints; S6: Establish the objective function, select the candidate action corresponding to the minimum value of the objective function as the optimal action of the calculation node, and execute it; S7: Calculate the queue backlog of each computing node in the next time slot, and execute step S2 at the beginning of the next time slot.

[0007] As a preferred embodiment of the above scheme, in step S1, initialization includes initializing hyperparameters, establishing hardware constraints, and creating virtual sub-queues for various types of data; the hyperparameters include weights for various types of data, performance-cost trade-off parameters, jitter reduction coefficients, potential energy influence factors, and unit transmission costs; the hardware constraints include physical bandwidth limits for each computing node, local computing power limits, and local storage write limits; the initial length of the virtual sub-queues for various types of data is 0.

[0008] As a preferred embodiment of the above scheme, in step S2, if the data in the virtual sub-queue exceeds the capacity limit, the excess data is discarded and the packet loss count is updated.

[0009] As a preferred embodiment of the above scheme, in step S3, the status information includes the length of each virtual sub-queue in the current time slot, the actual available local processing capacity of the computing node in the current time slot, and the transmission rate of the previous time slot.

[0010] As a preferred embodiment of the above scheme, in step S4, for computing nodes with neighboring nodes The weighted total pressure difference is expressed as: in, For a collection of data types, for Weights of class data For nodes In the time slot The queue-like backlog For nodes In the time slot The queue-like backlog Potential energy influencing factor and Representing nodes respectively with neighboring nodes The shortest hop count to the cloud exit. As a preferred embodiment of the above scheme, the action constraints in step S5 include: bandwidth constraint, the amount of data sent by the computing node to neighboring nodes is less than or equal to the available link bandwidth capacity of the computing node; computing capacity constraint, the amount of data processed locally by the computing node is less than or equal to the maximum computing capacity of the computing node; queue capacity constraint, the length of various types of virtual sub-queues is less than or equal to the upper limit of the capacity of various types of virtual sub-queues; non-negativity constraint, the amount of data sent by the computing node to neighboring nodes and the length of various types of virtual sub-queues are both greater than or equal to 0.

[0011] As a preferred embodiment of the above scheme, the objective function in step S6 is a Lyapunov optimization objective function, expressed as follows: in, As candidate actions, For performance-cost trade-off parameters, Resource consumption costs For local processing of revenue, To facilitate network traffic and revenue generation, To prevent vibration from causing penalties.

[0012] As a preferred embodiment of the above scheme, in step S7, the backlog of each queue in the next time slot of the computing node is expressed as follows: in, The length of the queue for the next time slot; This is the amount of data processed locally in this time slot; For this time slot to neighbors The amount of data sent; This is the amount of data received from neighbors in this time slot; This represents the amount of new data arriving in this time slot.

[0013] As a preferred option of the above scheme, the TD3 model with Lyapunov drift as a constraint penalty term is trained on the cloud side. The updated model is periodically distributed to each computing node. The computing node uses the distributed model to output hyperparameter adjustment amount according to the current state in each time slot to update the parameters of the local Lyapunov optimizer.

[0014] As a preferred embodiment of the above scheme, the TD3 model that incorporates Lyapunov drift as a constraint penalty term includes: a state space, in which the queue backlog, link utilization, and packet loss rate of each computing node are used as states. Motion space, using hyperparameter adjustments as motion parameters. The reward function is defined as the negative of the sum of weighted latency and packet loss rate, expressed as: in, For the first Average latency for similar services; For the first Packet loss rate for similar services; For the first Business-related delay weights; For the first Packet loss penalty coefficient for similar business operations.

[0015] The advantages of this invention are: it achieves differentiated scheduling of multiple services based on service weighted pressure difference, allowing high-priority services to be transmitted first in congested links, while meeting industrial control requirements in terms of latency; it combines node potential energy with Lyapunov optimization to achieve distributed decision-making, guiding global data convergence and avoiding ring network detours and local congestion; the bidirectional ring network, combined with an adaptive anti-jitter mechanism, enables millisecond-level self-healing of link faults, improving system stability; the algorithm is deployed at the application layer of edge nodes, requiring no modification to industrial switch hardware, resulting in low engineering implementation costs and strong compatibility. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the distributed data scheduling and load balancing method for industrial robot clusters in Example 1.

[0017] Figure 2 The curves show the change in the backlog of cold and hot data queues over time under dynamic congestion conditions in Example 2. Detailed Implementation

[0018] The technical solution of the present invention will be further described below through embodiments and in conjunction with the accompanying drawings.

[0019] Example: This embodiment describes a distributed data scheduling and load balancing method for industrial robot clusters, such as... Figure 1 As shown, it includes the following steps: S1: Establish and initialize a three-layer collaborative architecture comprising the edge, terminal, and cloud sides. The edge side consists of an industrial robot cluster responsible for collecting raw data and uploading it to the cloud side. This raw data includes control commands, sensor data, video streams, and logs. The cloud side is a bidirectional ring network consisting of multiple industrial computers and industrial switches. Each industrial computer is both a computing node and a network node, and the industrial switch handles high-speed material forwarding of data. The bidirectional ring network has two independent uplink exits connecting to the cloud side, enabling redundancy backup of critical paths. Each computing node in the bidirectional ring network has exactly two neighbor nodes, allowing for bidirectional data transmission. In this three-layer collaborative architecture, the bidirectional ring network acts as both a data transmission "pipeline" and a data "reservoir," temporarily storing data during congestion. The cloud side is a private or public cloud platform that receives data uploaded from the cloud side for long-term storage, analysis, and model training.

[0020] S2: The computing node receives data. In each time slot, the computing node receives two types of data: end-side uploaded data received from the robot and neighbor forwarded data received from the left / right neighbors of the ring network. The received data first enters the traffic classifier, which maps it to the tail of the corresponding virtual sub-queue based on the metadata in the packet header, such as data type identifier, source address, and priority label.

[0021] S3: For each computing node, read the status information of the current time slot, including the backlog of status information queue, hardware status, and historical transmission rate.

[0022] S4: Each computing node exchanges status information with its neighboring nodes and calculates the weighted total pressure difference between itself and its neighboring nodes. The weighted total pressure difference is obtained based on the sum of the various data backlog differences between adjacent computing nodes and the difference in the shortest path hop count between the target node.

[0023] S5: Each computing node establishes action constraints and enumerates candidate actions that satisfy the constraints. Action constraints include: bandwidth constraints, the amount of data sent by a computing node to neighboring nodes is less than or equal to the available link bandwidth capacity of the computing node; computing capacity constraints, the amount of data processed locally by a computing node is less than or equal to the maximum computing capacity of the computing node; queue capacity constraints, the length of various types of virtual sub-queues is less than or equal to the upper limit of the capacity of various types of virtual sub-queues; and non-negativity constraints, the amount of data sent by a computing node to neighboring nodes and the length of various types of virtual sub-queues are both greater than or equal to 0.

[0024] S6: Establish the objective function, select the candidate action corresponding to the minimum value of the objective function as the optimal action for this computation node, and execute it. The objective function is a Lyapunov optimization objective function.

[0025] S7: Calculate the queue backlog of each computing node in the next time slot, and execute step S2 at the beginning of the next time slot.

[0026] In step S1, initialization is performed during system startup. Initialization includes initializing hyperparameters, establishing hardware constraints, and creating virtual sub-queues for various types of data. Hyperparameters include: Business weight For hot data such as control commands and AI inference results, settings For cold data such as historical logs and archived backups, configure... Setting the raw sensor data ; The performance-cost trade-off parameter V typically has a range of values ​​of [value range missing]. A larger value tends to save transmission costs and reduce unnecessary transmission, while a smaller value tends to reduce latency and send data as soon as it is available. The anti-shake factor β typically ranges from 100 to 1000. This is used to suppress frequent route switching; the jitter reduction coefficient β is initially set to a value, and then adjusted adaptively for each time slot based on changes in the link transmission rate in historical time slots. Its calculation method is as follows: in, For nodes In the time slot oriented towards neighbor nodes The anti-shake coefficient; This is the minimum anti-shake coefficient of the system; Adjust parameters for jitter sensitivity; and These represent the link transmission rates for the first two time slots, respectively. This indicates the maximum bandwidth capacity of the link.

[0027] When the link transmission rate changes significantly Automatically increased to enhance the historical rate penalty in the objective function, thereby suppressing frequent link switching; when the network state is stable, To reduce congestion and improve the system's response speed to real-time congestion changes. Additionally, [further details are needed]. Set upper and lower limit constraints: in, The maximum permissible image stabilization factor; The minimum allowable image stabilization factor; The potential energy influence factor α typically ranges from 100 to 1000. This is used to adjust the strength of the influence of network location on data flow direction; Unit transmission cost It is defined as the normalized energy or bandwidth cost consumed in transmitting 1MB of data.

[0028] Hardware constraints include: the maximum physical bandwidth between each compute node and its left and right neighbors. and Units are Mbps or MB / s; local computing power limit The unit is tasks per second or MB / s; local storage write limit. The unit is MB / s.

[0029] Virtual subqueues for various types of data include: hot data queue It is used to store high-priority data such as control commands, alarm signals, and AI inference results; cold data queue It is used to store low-priority data such as system logs and historical archives; inference data queue Used to store AI inference tasks to be processed locally; raw data queue This queue is used to store raw sensor data awaiting preprocessing or forwarding. All queues have an initial length of 0.

[0030] In step S2, the specific data classification table is shown in the table below, and the data enqueue operation is as follows: New data volume. If the data in the virtual sub-queue exceeds the capacity limit, the excess data is discarded and the packet loss count is updated.

[0031] In step S3, the queue backlog is the length of each virtual sub-queue in the current time slot. The unit is MB or number of tasks; the hardware status is the current load rate of the CPU, NPU, and storage devices, and the actual available local processing capacity of the node for the current time slot is dynamically calculated based on resource usage. in, The available processing capacity of the node in the current time slot; This represents the maximum processing capacity of the node. This represents the combined load rate of CPU, NPU, and storage resources; the historical transmission rate is the transmission rate of the previous time slot. This is used for subsequent anti-shake calculations.

[0032] In step S4, when exchanging state information, the compute node sends information including the node ID and the current weighted backlog value to its left and right neighbors through an independent control channel. Hop count from node to cloud exit Hello packets containing information such as the node's hop count to the cloud egress are pre-calculated using the shortest path algorithm based on the ring network topology adjacency matrix and dynamically updated in case of link failure. Upon receiving a Hello packet from a neighboring node, the compute node obtains the weighted backlog value of that neighboring node. and the number of hops from the neighbor to the cloud exit Then, the weighted total pressure difference between the node and its neighboring nodes is calculated.

[0033] When calculating the weighted total differential pressure, first calculate its own time slot. The The backlog of a queue is defined as the total amount of data in the current queue that has not yet been sent or processed, and it is updated as follows: in, Represents a node In the time slot The Queue-like backlog; This indicates the amount of newly arrived data in the current time slot; Representing neighboring nodes Forward to node The amount of data; Represents a node Forward to neighboring nodes The amount of data; Represents a node The amount of data processed locally; Represents a node The set of neighboring nodes. Queue backlog is used to reflect the current real-time congestion level of a node.

[0034] Next, calculate the potential energy difference between the two nodes. The network potential value is defined as the number of hops along the shortest path to the nearest cloud egress node, and is calculated as follows: in, Represents a node The network potential energy value; This represents the set of all exit nodes connected to the cloud platform; Represents a node To the export node The number of hops for the shortest path.

[0035] The potential energy difference between nodes is defined as when When, it indicates neighboring nodes. The closer to the cloud exit, the more likely the system is to forward data to that neighboring node; when When the current node is closer to the cloud exit, the potential energy term will suppress the sending of data to the neighboring node, thereby avoiding invalid data routing in the ring network.

[0036] Finally, the weighted total pressure difference is calculated for each calculation node. with neighboring nodes The weighted total pressure difference is expressed as: in, Taking into account the backlog differences of all business types, hot data, due to its high weight, can generate a large pressure difference even if its volume is small. Based on the potential energy difference, data is guided to flow from nodes far from the cloud exit (high potential energy) to nodes close to the cloud exit (low potential energy), preventing data from circulating within the loop. For a collection of data types, for Weights of class data For nodes In the time slot The queue-like backlog For nodes In the time slot The queue-like backlog Potential energy influencing factor and Representing nodes respectively with neighboring nodes The shortest hop count to the cloud exit. The weighted total pressure difference essentially constructs a data flow-driven potential field that integrates business semantics and network topology information, enabling data to flow adaptively in the distributed network according to the principles of "high priority first, congestion priority guidance, and path approaching the exit".

[0037] The bandwidth constraint in step S5 is expressed as follows: , Represents a node Available link bandwidth capacity; computational capability constraints are expressed as , Represents a node Maximum computing power; queue capacity constraint is expressed as , Indicates the first The upper limit of queue capacity for similar business functions, expressed as a nonnegative constraint, is: , Indicates the first The upper limit of queue capacity for similar business functions.

[0038] In each time slot, the computing node first performs a feasibility constraint assessment on candidate actions based on the current link status, node resource status, and queue backlog. Only actions that meet the constraints are retained for subsequent objective function optimization. The specific action generation rules are as follows: When available bandwidth exists on the left link and the corresponding service queue contains data to be sent, actions that only transmit to the left are allowed to be generated. , Represents a node In the time slot The data rate sent to the left neighbor; This indicates the current available bandwidth on the left-hand link. Corresponding candidate action: Action A2 (transfer to the left only); Action A5 (Transfer to the left + Local processing).

[0039] When there is available bandwidth on the right link and there is data to be sent in the corresponding service queue, a right-only transmission action is allowed: , This indicates the current available bandwidth on the right-hand link. Corresponding candidate action: Action A3 (transfer to the right only); Action A6 (Transfer to the right + Local processing).

[0040] When the node's remaining computing resources meet the local processing requirements, local processing actions are allowed to be generated: , Represents a node Local processing rate in the current time slot; This indicates the available computing power of the node in the current time slot. Corresponding candidate actions: Action A4 (local processing only); Action A5 (Transfer to the left + Local processing); Action A6 (Transfer to the right + Local processing); Action A8 (bidirectional transmission + local processing).

[0041] When both left and right links meet the available bandwidth requirements, bidirectional transmission actions are allowed: , and Representing nodes respectively In the time slot Data transmission rate to left and right neighboring nodes; This indicates the maximum total bandwidth capacity of the node links. Corresponding candidate actions: Action A7 (bidirectional transmission); Action A8 (bidirectional transmission + local processing).

[0042] When all service queues are empty, or when both the link and computing resources are unavailable, the node enters an idle state, corresponding to the following candidate actions: Action A1 (Idle).

[0043] Subsequently, the node enumerates the set of candidate actions that satisfy the constraints, including: Action A1 (Idle): ; Action A2 (transfer to the left only): ; Action A3 (transfer to the right only): ; Action A4 (Local processing only): ; Action A5 (Transfer to the left + Local processing): ; Action A6 (Transfer to the right + Local processing): ; Action A7 (Bidirectional transmission): , must meet (If the ports share the total bandwidth); Action A8 (Bidirectional transmission + local processing): Bandwidth constraints must be met.

[0044] The set of candidate actions is not fixed, but is dynamically generated based on the link status, queue status and node resource status in the current time slot.

[0045] In step S6, the Lyapunov optimization objective function is expressed as: in, As candidate actions, For performance-cost trade-off parameters, Resource consumption costs For local processing of revenue, To facilitate network traffic and revenue generation, To prevent vibration from causing penalties.

[0046] Resource consumption cost is defined as in, Cost per unit of transmission; Calculate costs per unit; The rate at which a node sends data to its neighboring nodes; For the first Local processing rate of the service type. This item is used to quantify the network and computing resource consumption of the current action.

[0047] Local processing revenue is defined as in, This indicates the current backlog in the service queue. This item reflects the ability of the current action to alleviate local queue congestion.

[0048] Network diversion revenue is defined as in, This represents the weighted total pressure difference between nodes. This item reflects the contribution of the current action to the overall network congestion relief.

[0049] Anti-shake penalty is defined as This feature is used to suppress drastic changes in link transmission rates between consecutive time slots, thus avoiding frequent route switching.

[0050] The computing node iterates through all candidate actions that satisfy the constraints, selects the action with the smallest objective function value as the optimal scheduling strategy for the current time slot, and records the optimal local processing rate. Optimal leftward transmission rate Optimal rightward transmission rate and selecting the optimal action .

[0051] In step S6, when performing the optimal action, including data transmission and local processing, data transmission is performed according to business priority from high to low. Data is retrieved from the queue, encapsulated into frames, and sent to neighboring nodes via the left / right ports, updating port sending statistics. During local processing, for... The queue is processed by calling the AI ​​inference engine; for Queues are used to write data to local SSDs or HDDs for storage; CPU / storage load statistics are updated.

[0052] In step S7, the backlog of each queue in the next time slot of the computing node is expressed as follows: in, The length of the queue for the next time slot; This is the amount of data processed locally in this time slot; For this time slot to neighbors The amount of data sent; This is the amount of data received from neighbors in this time slot; This represents the amount of new data arriving in this time slot.

[0053] In this embodiment, to further enhance the algorithm's adaptability in dynamic industrial environments, the distributed Lyapunov optimization algorithm is combined with deep reinforcement learning. This enables the system to autonomously learn the optimal parameter configuration under different traffic patterns, achieving online adaptive adjustment of hyperparameters and improving average performance during long-term data acquisition. Specifically, the algorithm model is trained on the cloud side, and the updated model is periodically distributed to each computing node. The computing nodes use the distributed model to output hyperparameter adjustments based on the current state in each time slot to update the parameters of their local Lyapunov optimizer. The algorithm model adopts the Twin Delayed Deep Deterministic Policy Gradient (TD3) algorithm and introduces Lyapunov drift as a constraint penalty term, forming the LTD3 algorithm. This algorithm effectively reduces the overestimation problem of the value function through a dual Critic network and delayed policy updates, making it suitable for control tasks in continuous action spaces.

[0054] The LTD3 algorithm includes a state space, which uses the queue backlog, link utilization, and packet loss rate of each computing node as states. Motion space, using hyperparameter adjustments as motion parameters. The reward function is defined as the negative of the sum of weighted latency and packet loss rate, expressed as: in, For the first Average latency for similar services , For the first The actual delay of each data packet This represents the total number of business data within a time slot. For the first Packet loss rate for similar services , This represents the number of packets lost within a time slot. The total number of data packets arriving in the queue within the time slot; For the first The delay weight for different business types is set according to the priority of the business type; the higher the weight, the smaller the delay. For the first The packet loss penalty coefficient for each type of service is set according to the importance of the service.

[0055] The distributed data scheduling and load balancing method for industrial robot clusters in this embodiment constructs a distributed scheduling mechanism of "weighted differential pressure drive + multi-action joint optimization" to achieve adaptive data flow and collaborative resource allocation in the industrial robot cluster network. This ensures the real-time performance of high-priority services while achieving overall system load balancing and stable operation.

[0056] Example 2: This embodiment demonstrates the application of the solution in Embodiment 1 in a robot cluster scenario in an automotive welding workshop.

[0057] The automotive welding workshop has deployed a welding station cluster consisting of six industrial robots. Each robot is equipped with a high-definition vision sensor and a force sensor to collect welding process data in real time. The edge layer consists of a two-way ring network composed of three industrial computers (IPC-1, IPC-2, and IPC-3). Each IPC connects to two robots, and both ends of the ring network are connected to a private cloud through independent exits.

[0058] The data generated in the workshop is divided into three categories: Thermal data includes robot emergency stop signals, real-time welding quality alarms, and abnormal process parameter alarms, with an end-to-end delay of less than 10ms required.

[0059] Temperature data: AI visual inspection results (such as solder joint defect recognition) are required to have a latency of less than 100ms.

[0060] Cold data: Welding process logs and video stream backups, with no real-time requirements and tolerable delays down to the second.

[0061] In this embodiment, to simplify the calculation, only two types of data are considered: hot data and cold data, with weights set as follows: Other parameter settings are as follows: Performance-cost trade-off parameters ; Initial value of anti-shake coefficient ; Potential energy influence factor ; Unit transmission cost (Normalized value); Maximum bandwidth of each edge computing node (IPC) port ; Local processing capacity limit (Used for cold data storage or AI inference).

[0062] Suppose at some moment The queue backlog status of the three edge computing nodes (IPCs) is shown in the table below: IPC-2 and IPC-3 are both directly connected to the exit node (hop count is 1), while IPC-1 needs to go through IPC-2 or IPC-3 to reach the exit (hop count is 2).

[0063] At this time, IPC-1 had a large backlog of cold data and a small amount of sudden hot data, which urgently needed to be released; IPC-2 was completely idle; IPC-3 also had some backlog, but more hot data.

[0064] Taking IPC-1 as an example, the execution process is as follows: In each time slot ( IPC-1 performs the following steps: S01: Local State Awareness and Neighbor Information Interaction IPC-1 reads the local queue: .

[0065] Calculate the local weighted backlog: IPC-1 broadcasts a Hello packet to its neighbors IPC-2 and IPC-3. .

[0066] In this context, hot data has a weight of 100, and cold data has a weight of 1.

[0067] Simultaneously receive neighbor information: From IPC-2: ; From IPC-3: .

[0068] S02: Calculate the weighted total pressure difference For the left neighbor IPC-2 For the right neighbor IPC-3 The calculation results show that IPC-1 is much more congested than IPC-2 (pressure difference 700.5), so data should be sent to IPC-2; while IPC-3 is more congested than IPC-1 (pressure difference 0), so data should not be sent to IPC-3.

[0069] S03: Enumerate candidate actions and calculate the objective function IPC-1 considers candidate actions as shown in the table below. For simplicity, only meaningful actions are listed, and local processing is limited to cold data storage: Local processing revenue items Pick Because the length of the cold data queue is 500.

[0070] During system operation, β is dynamically updated based on changes in the historical link rate.

[0071] S04: Select the optimal action Comparing the J values ​​of each action, A3 (full transmission to the left + local processing) has the smallest J value (-94400). Therefore, IPC-1 selects action A3: send data to its left neighbor IPC-2 at a rate of 100 MB / s, while simultaneously processing cold data locally at a rate of 50 MB / s (such as writing to the SSD).

[0072] S05: Execution and Update Data transmission: IPC-1 transmits 2MB from the hot data queue first, and then transmits 98MB from the cold data queue according to service priority (100MB / s rate, a total of 100MB is transmitted in this time slot).

[0073] Local processing: Take 50MB from the cold data queue and store it.

[0074] Queue update: Hot data queue: 2-2=0; Cold data queue: 500 - 98 (sent) - 50 (local processing) = 352MB (assuming no new data arrives).

[0075] At the start of the next time slot, the queue backlog for IPC-1 decreased significantly.

[0076] Responses from other nodes (taking IPC-2 as an example) After receiving 100MB of data from IPC-1, IPC-2 updates its queue status: During data reception, 2MB of hot data entered. 98MB of cold data entered .

[0077] New queue: =2MB, =98MB.

[0078] The weighted backlog of IPC-2 becomes: .

[0079] IPC-2's neighbors include IPC-1. and Calculate the pressure difference: For IPC-1: ; For IPC-3: .

[0080] The pressure difference is 0, indicating that IPC-2 is not in a hurry to forward data to any neighbor and can choose to process it locally or temporarily store it. Since IPC-2 is directly connected to the cloud egress (… With ample outbound bandwidth, it prioritizes sending hot data directly to the cloud via the outbound channel, while cold data can be temporarily stored or forwarded later.

[0081] To further verify the dynamic response capability of the distributed data scheduling and load balancing method for industrial robot clusters under continuous time domain and extreme congestion conditions, dynamic scenario verification was conducted using network simulation tools based on the aforementioned network topology of the automotive welding workshop robot cluster.

[0082] 1. Dynamic experimental scenario configuration Phase 1 (Regular Load): During the period from 0s to 2.0s, the system is in steady state and there is no network congestion.

[0083] Phase 2 (Cold Data Congestion): Starting from 2.0s, the simulated edge robot suddenly performs a massive video stream backup task, continuously injecting cold data into IPC-1 at a rate of 2 data packets per millisecond (exceeding the single node processing limit), forming a net backlog rate of 1 data packet per millisecond.

[0084] Phase 3 (Hot Data Alarm): At 4.0s, the simulated robot generates an emergency stop signal (hot data) and instantaneously injects 30 high-priority data packets.

[0085] Phase 4 (Traffic Recovery): At 8.0s, the large-scale injection of cold data on the end side ends, and the system enters the phase of relieving backlog and self-healing recovery.

[0086] 2. Dynamic Scheduling Process Analysis like Figure 2 As shown, the system exhibits the following technical characteristics through a distributed scheduling algorithm based on Lyapunov optimization: Backlog Sensing and Proactive Balancing: During the period from 2.0s to 4.0s, as cold data is continuously injected, the backlog of the cold data queue ( The backlog increased linearly, exceeding 2000 packets by 4.0s. At this point, the algorithm detected the weighted pressure difference between the local and neighboring nodes and began to fully utilize bandwidth to divert traffic to the egress node.

[0087] "Zero backlog" transmission of high-priority services: During the 4.0s burst of hot data, although the physical link and cold data queue are already extremely congested, the transmission is still possible due to the weighting of the hot data (…). The weight of cold data is much greater than that of cold data. The algorithm calculates that hot data has absolute transmission priority. For example... Figure 2 Hot data queue backlog ( As shown in the figure, all thermal data is transmitted within a very short time after arrival, and its backlog curve remains close to the 0 mark throughout the entire observation period, achieving real-time transmission across congestion.

[0088] Congestion self-healing and system stability: After the flow source stops at 8.0s, the system continues to perform margin drainage through differential pressure drive. The curve descends smoothly from its peak, demonstrating that the algorithm has the ability to quickly self-heal after experiencing extreme sudden traffic surges.

[0089] The dynamic simulation results above demonstrate that the distributed data scheduling and load balancing method for industrial robot clusters in this embodiment can effectively cope with sudden traffic surges in industrial settings. Even under extreme conditions of full physical link load, the weighted differential pressure mechanism can still ensure that the queuing delay of hot data (such as alarms and control commands) approaches zero, completely breaking the traditional first-in-first-out queue's blocking of critical commands during congestion, and meeting the stringent requirements of high reliability and low latency in industrial control scenarios.

[0090] The specific embodiments described herein are merely illustrative of the spirit of the invention. Those skilled in the art to which this invention pertains may make various modifications or additions to the described specific embodiments or use similar methods to substitute them, without departing from the spirit of the invention or exceeding the scope defined by the appended claims.

Claims

1. A distributed data scheduling and load balancing method for industrial robot clusters, characterized by: Includes the following steps: S1: Establish and initialize a three-layer collaborative architecture including the edge, cloud, and terminal sides; the edge side consists of an industrial robot cluster, responsible for collecting raw data and uploading it to the terminal side; the terminal side is a bidirectional ring network of multiple industrial computers and industrial exchange mechanisms, with each industrial computer serving as a computing node and each computing node having two neighbor nodes; the cloud side receives the data uploaded by the terminal side for long-term storage, analysis, and model training. S2: The computing node receives data, classifies the received data, and maps it to the tail of the corresponding virtual sub-queue; S3: For each computing node, read the status information of the current time slot; S4: Each computing node exchanges status information with its neighboring nodes and calculates the weighted total pressure difference with its neighboring nodes. The weighted total pressure difference is obtained based on the sum of various data accumulation differences between adjacent computing nodes and the difference in the shortest path hop count between the target node. S5: Establish action constraints for each computing node and enumerate candidate actions that satisfy the action constraints; S6: Establish the objective function, select the candidate action corresponding to the minimum value of the objective function as the optimal action of the calculation node, and execute it; S7: Calculate the queue backlog of each computing node in the next time slot, and execute step S2 at the beginning of the next time slot.

2. The distributed data scheduling and load balancing method for industrial robot clusters according to claim 1, characterized in that: In step S1, initialization includes initializing hyperparameters, establishing hardware constraints, and creating virtual sub-queues for various types of data. The hyperparameters include weights for various types of data, performance-cost trade-off parameters, jitter reduction coefficients, potential energy influence factors, and unit transmission costs. The hardware constraints include physical bandwidth limits for each computing node, local computing power limits, and local storage write limits. The initial length of the virtual sub-queues for various types of data is 0.

3. The distributed data scheduling and load balancing method for industrial robot clusters according to claim 1, characterized in that: In step S2, if the data in the virtual sub-queue exceeds the capacity limit, the excess data is discarded and the packet loss count is updated.

4. The distributed data scheduling and load balancing method for industrial robot clusters according to claim 1, characterized in that: In step S3, the status information includes the length of each virtual sub-queue in the current time slot, the actual available local processing capacity of the computing node in the current time slot, and the transmission rate of the previous time slot.

5. The distributed data scheduling and load balancing method for industrial robot clusters according to claim 1, characterized in that: In step S4, for computing nodes with neighboring nodes The weighted total pressure difference is expressed as: in, For a collection of data types, for Weights of class data For nodes In the time slot The queue-like backlog For nodes In the time slot The queue-like backlog Potential energy influencing factor and Representing nodes respectively with neighboring nodes The shortest number of hops to the cloud exit.

6. The distributed data scheduling and load balancing method for industrial robot clusters according to claim 1, characterized in that: The action constraints in step S5 include: bandwidth constraint, the amount of data sent by the computing node to neighboring nodes is less than or equal to the available link bandwidth capacity of the computing node; computing capacity constraint, the amount of data processed locally by the computing node is less than or equal to the maximum computing capacity of the computing node; queue capacity constraint, the length of various types of virtual sub-queues is less than or equal to the upper limit of the capacity of various types of virtual sub-queues; and non-negativity constraint, the amount of data sent by the computing node to neighboring nodes and the length of various types of virtual sub-queues are both greater than or equal to 0.

7. The distributed data scheduling and load balancing method for industrial robot clusters according to claim 1, characterized in that: In step S6, the objective function is a Lyapunov optimization objective function, expressed as follows: As candidate actions, For performance-cost trade-off parameters, Resource consumption costs For local processing of revenue, To facilitate network traffic and revenue generation, To prevent vibration from causing penalties.

8. The distributed data scheduling and load balancing method for industrial robot clusters according to claim 1, characterized in that: In step S7, the backlog of each queue in the next time slot of the computing node is expressed as follows: in, The length of the queue for the next time slot; This is the amount of data processed locally in this time slot; For this time slot to neighbors The amount of data sent; This is the amount of data received from neighbors in this time slot; This represents the amount of new data arriving in this time slot.

9. The distributed data scheduling and load balancing method for industrial robot clusters according to claim 1, characterized in that: The TD3 model, which incorporates Lyapunov drift as a constraint penalty term, is trained on the cloud side. The updated model is periodically distributed to each computing node. The computing nodes use the distributed model to output hyperparameter adjustments based on the current state in each time slot to update the parameters of the local Lyapunov optimizer.

10. The distributed data scheduling and load balancing method for industrial robot clusters according to claim 9, characterized in that: The TD3 model that incorporates Lyapunov drift as a constraint penalty includes: a state space, where the queue backlog, link utilization, and packet loss rate of each computing node are used as states. Motion space, using hyperparameter adjustments as motion parameters. The reward function is defined as the negative of the sum of weighted latency and packet loss rate, expressed as: For the first Average latency for similar services; For the first Packet loss rate for similar services; For the first Business-related delay weights; For the first Packet loss penalty coefficient for similar business operations.

Images