Refrigeration cluster cooperative scheduling method and system, and storage medium

Abstract

This application discloses a cooling cluster collaborative scheduling method, system, and storage medium, applied to a three-level control architecture including a regional control layer, a building control layer, and an equipment terminal layer. The method includes: collecting cooling demand information for each building and operating status information for each device within a scheduling cycle; dividing the cooling demand into first-priority loads, second-priority loads, and third-priority loads based on whether cooling reduction or postponement is permitted; generating building quota data packets from the regional control layer and sending them to the building control layer; generating equipment control data packets from the building quota data packets and sending them to the equipment terminal layer; mapping load shares to equipment execution control quantities and returning status acknowledgments from the equipment terminal layer; performing retransmission if the building control layer does not receive a status acknowledgment within a preset acknowledgment time limit, and reallocating third-priority loads and / or activating backup equipment according to a preset degradation strategy if retransmission fails; and performing incremental rescheduling on the affected building set and equipment set when the deviation between the actual load and the predicted load, equipment abnormality, or the supply deviation of the first-priority load meets preset trigger conditions. By implementing hierarchical data packet distribution, closed-loop delivery receipts, and incremental rescheduling triggered by anomalies, the reliability of cluster scheduling and overall operational efficiency can be improved while ensuring the stability of cooling supply to critical loads.

Description

Technical Field

[0001] This application relates to the field of cooling cluster control and hierarchical scheduling technology, and in particular to a cooling cluster collaborative scheduling method, system and storage medium applicable to campus cooling stations, multi-building centralized cooling systems, commercial complex cold source systems, industrial cooling systems and data center cooling systems. Background Technology

[0002] In scenarios such as industrial parks, commercial complexes, regional energy stations, and data centers, cooling systems typically operate in a network configuration involving multiple buildings, multiple cooling stations, and multiple types of cooling equipment. Due to differences in building uses, varying population densities, and significant differences in equipment operating conditions, the actual cooling demand exhibits obvious time-varying and sudden characteristics. Furthermore, the rated capacity, operational limits, energy efficiency curves, start-up and shutdown costs, and communication quality of different equipment also vary.

[0003] Among existing control schemes, one type employs single-site local control or fixed-ratio allocation. While simple to implement, this approach fails to comprehensively consider load priorities and equipment energy efficiency differences between different buildings at the regional scale, potentially leading to insufficient protection of high-priority loads or excessive overall energy consumption. Another type of scheme, while introducing centralized optimization solutions, often directly outputs device-level control results, resulting in a lack of clear boundaries between upper and lower level controlled objects. When communication link jitter, equipment feedback loss, or local device failure occurs, the system is prone to problems such as duplicate execution, instruction mismatch, or excessive global recalculation overhead.

[0004] Furthermore, in practical engineering, different types of loads have different requirements for cooling continuity. For example, critical computer rooms, cold chain spaces, or process equipment often cannot tolerate interruptions in cooling, while public areas, corridors, or non-critical areas are allowed flexible adjustments within a certain time window. Existing solutions often fail to organically combine load priority constraints, hierarchical allocation, equipment execution boundaries, and anomaly feedback closed-loop, thus making it difficult to balance critical load assurance, dispatch reliability, and overall system energy efficiency. Summary of the Invention

[0005] The purpose of this application is to provide a cooling cluster collaborative scheduling method, system, and storage medium to at least solve one of the following problems existing in the prior art: First, the lack of a clear hierarchical interface between upper-level scheduling and equipment execution makes it difficult for control commands to be stably implemented in multi-building scenarios; Second, the lack of differentiated control mechanisms for critical loads, flexible loads, and loads that can be reduced results in insufficient critical cooling supply guarantee capabilities; Third, the lack of a repeatable and verifiable feedback closed-loop and incremental rescheduling mechanism in the face of communication anomalies or equipment failures results in insufficient control reliability.

[0006] To achieve the above objectives, this application provides a cooling cluster collaborative scheduling method, which is applied to a three-level control architecture including a regional control layer, a building control layer, and an equipment terminal layer. The regional control layer outputs building-level quotas, the building control layer outputs equipment-level control data packets, and the equipment terminal layer executes equipment control quantities and returns status acknowledgments, thereby forming a control link that is distributed and converged step by step.

[0007] In a preferred embodiment, the regional control layer does not directly issue control variables to the device terminal layer. Instead, it first generates building quota data packets. The building control layer then locally combines the executable boundaries, start / stop states, energy efficiency curves, and comfort constraints of the devices within the building to convert the building quota data packets into device control data packets. This approach decouples regional-level coordination from building-level execution, reduces the complexity of the global model, and enables the building side to quickly adjust based on local device status.

[0008] In a preferred embodiment, the required cooling capacity is divided into first-priority loads, second-priority loads, and third-priority loads based on whether cooling capacity can be reduced or delayed. First-priority loads are given priority, second-priority loads allow for short-term flexible adjustments, and third-priority loads allow for reduction and / or peak shifting. This load stratification allows the regional control layer to prioritize critical cooling capacity needs when cooling capacity is limited or the supply chain is abnormal.

[0009] In a preferred embodiment, both building quota data packets and device control data packets adopt a packetized structure with tags, and a set of processed data packet tags is maintained at the building control layer and the device terminal layer. By introducing idempotent tags and a deduplication mechanism for duplicate arrivals, the repeated execution of the same control command under network jitter or retransmission conditions can be avoided.

[0010] In a preferred embodiment, device control data packets corresponding to the first priority load are set to require a receipt. If the building control layer does not receive a status receipt within a preset receipt time limit, a retransmission is performed; after consecutive retransmission failures, a degradation strategy is initiated. The degradation strategy may include activating backup equipment, reducing the cooling share of the third priority load, or performing limited flexible adjustments on the second priority load. This mechanism can ensure the cooling continuity of critical loads in the event of communication or equipment failure.

[0011] In a preferred embodiment, when the deviation between the actual load and the predicted load, the abnormal state of equipment, or the supply deviation of the first priority load meets a preset trigger condition, incremental rescheduling is performed only for the affected set of buildings and equipment, rather than a global recalculation of all buildings and all equipment. By using the decision result of the previous scheduling cycle as the initial solution, the solution time can be shortened and the scheduling response speed under abnormal conditions can be improved.

[0012] Compared with existing technologies, this application has at least the following beneficial effects: It effectively decouples regional collaboration from building execution through a three-tiered interface of regional control layer—building control layer—equipment terminal layer; it achieves an auditable, deduplicatable, and acknowledgable control link through the hierarchical distribution of building quota data packets and equipment control data packets; it improves the cooling supply guarantee capability of critical loads through priority load allocation, mandatory acknowledgment, retransmission, and degradation mechanisms; and it reduces the recalculation scale under abnormal operating conditions through affected subset screening and incremental rescheduling, thereby improving control reliability while taking into account overall operational energy efficiency. Attached Figure Description

[0013] Figure 1 This is a schematic diagram of the three-level control architecture and data flow of a cooling cluster according to an embodiment of this application; Figure 2 This is a flowchart of a cooling cluster collaborative scheduling method according to an embodiment of this application; Figure 3 This is a schematic diagram of a building quota data packet, equipment control data packet, and receipt closed loop according to an embodiment of this application; Figure 4 This is a schematic diagram of an abnormal triggering incremental rescheduling according to one embodiment of this application. Detailed Implementation

[0014] The present application will now be described in further detail with reference to the accompanying drawings and specific embodiments. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present application. Where there is no conflict, the technical features in the following embodiments can be combined with each other.

[0015] In this application, the regional control layer can be deployed on a campus-level control server, a cloud coordination platform, or a regional energy station control center; the building control layer can be deployed on a building-level controller, an edge controller, or a chiller station local controller; and the equipment terminal layer can be deployed on chillers, chilled water pumps, cooling water pumps, cooling towers, terminal valve actuators, and control units that are associated with the above equipment.

[0016] In this application, the required cooling capacity information can be obtained by conversion, calculation, or fitting from chilled water flow rate, supply and return water temperature difference, area temperature and humidity, equipment load rate, process load demand, or historical cooling records. Operating status information may include equipment availability, current load rate, start / stop status, alarm status, communication quality, rated capacity, minimum stable load, current energy efficiency parameters, upper and lower limits of operability, etc.

[0017] For ease of description, this application classifies loads into three priority categories. The first priority load primarily characterizes uninterrupted cooling loads, such as critical computer rooms, cold chain spaces, core process sites, or areas sensitive to temperature deviations. The second priority load primarily characterizes loads that allow for flexible adjustment within short time windows, such as business areas, public service areas, or non-critical process areas. The third priority load primarily characterizes loads that allow for reduction and / or peak shifting, such as corridors, ancillary areas, parking lots, or pre-cooling loads during non-critical periods. The above classification is merely illustrative, and this application is not limited to specific application scenarios.

[0018] like Figure 1 As shown, the cooling cluster system of this embodiment includes a regional control layer 1, a building control layer 2, an equipment terminal layer 3, a first communication link 4, and a second communication link 5. The regional control layer 1 and the building control layer 2 transmit building quota data packets 6 via the first communication link 4; the building control layer 2 and the equipment terminal layer 3 transmit equipment control data packets 7 and status receipts 8 via the second communication link 5. The regional control layer 1 is used to perform load aggregation, priority coordination, and building quota allocation at the regional scale; the building control layer 2 is used to perform equipment-level allocation based on the equipment boundaries within the building; and the equipment terminal layer 3 is used to execute equipment control variables and return the execution results.

[0019] The regional control layer 1 may include a load forecasting unit 11, a priority allocation unit 12, a building quota generation unit 13, and a rescheduling triggering unit 14. The load forecasting unit 11 generates forecasted loads based on historical loads, environmental parameters, business rhythms, process plans, or equipment status; the priority allocation unit 12 performs priority classification on demand cooling capacity; the building quota generation unit 13 generates building quota data packages 6 for each building based on the forecast results, current available equipment capacity, and preset redundancy constraints; the rescheduling triggering unit 14 is used to initiate incremental rescheduling when load mutations, equipment anomalies, or critical load supply deviations are detected.

[0020] The building control layer 2 may include a device candidate filtering unit 21, a device control data packet generation unit 22, a receipt management unit 23, and a degradation processing unit 24. The device candidate filtering unit 21 determines a set of candidate devices based on the current availability, energy efficiency parameters, start-up and shutdown costs, and execution boundaries of the devices in the building; the device control data packet generation unit 22 converts the building quota into device control data packets 7; the receipt management unit 23 completes confirmation, deduplication, and timeout determination based on the status receipts 8; and the degradation processing unit 24 calls up backup devices or reallocates low-priority loads when retransmission fails or devices are unreachable.

[0021] The device terminal layer 3 may include an execution mapping unit 31 and an execution feedback unit 32. The execution mapping unit 31 is used to convert the load share in the device control data packet 7 into device control quantities such as compressor frequency, valve opening degree, water pump flow rate or cooling tower fan speed; the execution feedback unit 32 is used to collect the device status after execution and generate a status receipt 8 for reporting.

[0022] like Figure 2 As shown, the cooling cluster collaborative scheduling method of this embodiment may include the following steps: S101: Collect cooling demand information and equipment operation status information of each building within the scheduling cycle. The scheduling cycle can be set from 1 minute to 15 minutes, preferably 5 minutes, depending on the system scale, communication conditions, and equipment response speed. In practical applications, each building can first complete local filtering and outlier removal at the building control layer 2 before reporting to the area control layer 1.

[0023] S102: Cooling demand is categorized into first-priority loads, second-priority loads, and third-priority loads based on whether reductions or postponements of cooling supply are permitted. Priority allocation can be based on building type, area use, process requirements, comfort boundaries, contractual agreements, or pre-set rules. Different areas within the same building can also be assigned to different priorities.

[0024] S103: The area control layer 1 generates building quota data packets 6. Based on the total cooling demand, building weight, priority requirements, equipment availability, and redundancy constraints, the area control layer 1 generates the total cooling quota and priority cooling quota for each building, and encapsulates the corresponding results into building quota data packets 6 and sends them to the corresponding building control layer 2.

[0025] S104: The building control layer 2 generates the device control data packet 7 based on the building quota data packet 6 and the executable boundaries of each device in the building. The executable boundaries may include the device's rated capacity, minimum stable load, current temperature boundary, frequency variation limit, valve opening limit, pump flow limit, and nighttime noise constraints, etc.

[0026] S105: The load share is mapped to the control quantity executed by the equipment terminal layer 3 and then executed. For variable frequency chillers, the load share can be mapped to the compressor target frequency; for variable frequency pumps, the load share can be mapped to the target flow rate or target speed; for valve actuators, the load share can be mapped to the target opening degree. To avoid mechanical shock and hydraulic fluctuations, the change in control quantity between adjacent time points can be constrained by ramp-up limits.

[0027] S106: Status receipt 8 is returned by device terminal layer 3. Building control layer 2 confirms the receipt based on status receipt 8 and performs retransmission if no receipt is received within the timeout period. Status receipt 8 may include at least the device identifier, the data packet identifier corresponding to the receipt, the actual execution result, the current load rate, the current executable boundary, and the exception code.

[0028] S107: Incremental rescheduling is performed when preset trigger conditions are met. The trigger conditions may include actual load deviation from predicted load exceeding a threshold, equipment failure, communication unavailability, critical load supply deviation exceeding limits, etc. Incremental rescheduling prioritizes screening the affected building set and the affected equipment set, and uses the decision result of the previous scheduling cycle as the initial solution, resolving only the affected objects.

[0029] like Figure 3 As shown, the building quota data packet 6, equipment control data packet 7, and status receipt 8 can adopt a hierarchical data packet structure. The building quota data packet 6 may include a data packet identifier 61, a building identifier 62, total quota cooling capacity 63, first priority quota cooling capacity 64, second priority quota cooling capacity 65, third priority quota cooling capacity 66, energy efficiency lower limit 67, standby redundancy ratio 68, and validity period 69. The equipment control data packet 7 may include a device data packet identifier 71, parent data packet identifier 72, device identifier 73, load share 74, target setpoint 75, execution boundary 76, receipt requirement flag 77, and idempotency flag 78. The status receipt 8 may include a receipt corresponding identifier 81, execution result code 82, current load rate 83, current energy efficiency parameter 84, and abnormal status 85.

[0030] In one embodiment, both the building control layer 2 and the device terminal layer 3 maintain a set of processed data packet identifiers. When duplicate data packets arrive due to network jitter, buffer replay, or upper-layer retransmission, the receiver first determines whether the data packet has been processed based on the idempotency identifier. If it has been processed, the receiver returns the corresponding status receipt 8 without repeating the control action, thus preventing the device from repeatedly changing its settings in a short period of time.

[0031] In one embodiment, the device control data packet 7 corresponding to the first priority load is set to require a receipt. If the building control layer 2 does not receive a status receipt 8 within a preset receipt time limit, it can retransmit the data packet according to the original data packet identifier. If a preset number of retransmissions is reached and no receipt is received, the receipt management unit 23 marks the device as unreachable or failed to execute, and notifies the degradation processing unit 24 to perform degradation processing.

[0032] Degradation can be implemented in several ways. The first is to activate backup equipment, selecting devices from the standby pool with lower startup costs and that meet current requirements to supplement cooling capacity. The second is to reduce the cooling share of the area corresponding to the third-priority load, releasing redundant cooling capacity. The third is to perform short-term, flexible adjustments to the second-priority load, provided that preset comfort levels or process boundaries allow. Through these methods, even in the event of partial equipment failure or malfunction, the first-priority load can be prioritized for cooling.

[0033] like Figure 4 As shown, when an anomaly is detected, the system does not necessarily perform a global recalculation of all buildings and all equipment. Instead, it first performs a subset screening of affected units. Specifically, the affected building set 91 is selected based on the contribution of each building to the total deviation, the current load rate of the equipment in each building, the presence of anomaly codes, and communication quality information. Subsequently, within the affected building set 91, the affected equipment set 92 is selected that has a load rate exceeding a threshold, returns to an abnormal state, or is unreachable. The allocation result of the previous scheduling cycle is used as the initial solution 93 in the area control layer 1, and only the affected building set 91 and the affected equipment set 92 are re-solved to form the incremental rescheduling result 94.

[0034] In a preferred embodiment, the affected building set 91 can be selected as the buildings ranking in the top 30% of deviation contribution, and the affected equipment set 92 can be selected as equipment with a load rate exceeding 85% or with anomaly codes. The above thresholds are only examples and can be adjusted according to project scale and scheduling requirements in actual applications. By solving for a subset instead of the entire set of objects, the scale of rescheduling computation can be significantly reduced, thereby improving response efficiency under abnormal operating conditions.

[0035] The following describes the operation of this application using a specific application scenario. Assume a certain industrial park comprises five buildings, each equipped with a chiller unit, chilled water pump, cooling water pump, and terminal control valve. The area control layer 1 operates on a 5-minute scheduling cycle. At the start of the k-th scheduling cycle, area control layer 1 receives cooling demand information, equipment availability, current load rate, and communication status from the building control layers 2.

[0036] The regional control layer 1 first divides the required cooling capacity into three priority categories: first priority loads are assigned to critical computer rooms and cold chain areas; second priority loads are assigned to office areas, core commercial areas, or process auxiliary areas; and third priority loads are assigned to corridors, ancillary areas, and pre-cooling loads that allow for delayed cooling. Subsequently, the regional control layer 1 generates building quota data packages 6 based on the average energy efficiency of each building, equipment availability, and a 10% redundancy constraint, and distributes them to the corresponding building control layer 2.

[0037] After receiving the building quota data packet 6, the building control layer 2 prioritizes allocating the first priority load to high-energy-efficiency devices with sufficient current operational limits, allocates the second priority load to the set of devices that can be flexibly adjusted, and reserves the third priority load for adjustment space that can be reduced or shifted. Subsequently, the building control layer 2 generates the device control data packet 7 and sends it to the device terminal layer 3 via the second communication link 5.

[0038] After receiving the equipment control data packet 7, the equipment terminal layer 3 converts the load share into a specific control quantity. For example, for a variable frequency chiller, the load share can be mapped to a compressor target frequency of 30 Hz to 60 Hz according to a preset linear or piecewise linear relationship; for a variable frequency pump, the load share can be mapped to a target flow rate, and the change per minute is limited to not exceeding a preset ramp limit. After execution, the equipment terminal layer 3 feeds back the execution result through a status feedback 8.

[0039] When the regional control layer 1 detects a sudden increase in load in a building, an error code returned by a device, or a first-priority load supply deviation exceeding a threshold, the rescheduling trigger unit 14 initiates incremental rescheduling. The regional control layer 1 first determines the affected building set 91 and the affected device set 92, recalculates only the relevant objects, and, if necessary, calls the building control layer 2 to perform degradation processing. In this way, the cooling stability of critical loads can be quickly restored without expanding the solution scope.

[0040] This application also provides a refrigeration cluster collaborative scheduling system. The system includes a regional control module, a building control module, an equipment terminal module, and a communication module. Each module can be implemented using hardware, software, firmware, or any combination thereof. Specifically, the regional control module can be implemented using a server, industrial computer, or cloud platform; the building control module can be implemented using an edge controller, PLC, or building automation controller; and the equipment terminal module can be implemented using an equipment control board, frequency converter control unit, actuator control unit, or a combination thereof.

[0041] This application also provides a non-transitory computer-readable storage medium storing a computer program. When executed by a processor, the computer program causes the processor to perform the cooling cluster collaborative scheduling method in any of the above embodiments. The storage medium can be a hard disk, solid-state drive, flash memory, read-only memory, random access memory, or other media capable of storing program code.

[0042] It should be noted that the terms "first," "second," and "third" in this application are used only to distinguish different objects and are not used to limit the importance, order, or quantity of the objects. Unless otherwise expressly defined, the terms "including" and "comprising" in this application should be understood as open-ended expressions, indicating that in addition to the listed technical features, other technical features not explicitly listed but which are commonly used by those skilled in the art may also be included.

[0043] The above embodiments are merely preferred embodiments of this application and are not intended to limit this application. For those skilled in the art, various substitutions, modifications, and combinations can be made to the above embodiments without departing from the spirit and substance of this application, and such substitutions, modifications, and combinations should all fall within the protection scope of this application.

Claims

1. A method for collaborative scheduling of a cooling cluster, characterized in that, Applied to a three-tier control architecture comprising a regional control layer, a building control layer, and a device terminal layer, the method includes: - Collect cooling demand information for each building and operating status information for each piece of equipment during the scheduling cycle; - Based on whether cooling demand can be reduced or postponed, cooling demand is divided into first-priority load, second-priority load, and third-priority load; - The regional control layer generates building quota data packets for each building based on the cooling demand information, equipment operation status information, and preset redundancy constraints of each building, and sends them to the building control layer. The building quota data packets include at least the building identifier, total quota cooling capacity, quota cooling capacity for each priority level, and validity period. - The building control layer generates and distributes device control data packets to the device terminal layer based on the received building quota data packets and the executable boundaries of each device in the building. The device control data packets include at least the device identifier, the corresponding load share, the target set value, and the execution boundary. - The device terminal layer maps the load share to the device execution control quantity and executes the control. After execution, it returns a status receipt to the building control layer. - The building control layer confirms the status receipt of the device control data packet. If a status receipt is not received within a preset receipt time limit, retransmission is performed. If retransmission fails, the third priority load is reallocated and / or backup equipment is activated according to a preset degradation strategy. - When the deviation between the actual load and the predicted load, the abnormal state of the equipment, or the supply deviation of the first priority load meets the preset trigger conditions, incremental rescheduling is performed on the affected building set and equipment set.

2. The cooling cluster collaborative scheduling method according to claim 1, characterized in that, The first priority load is the uninterrupted cooling load, the second priority load is the cooling load that allows for short-term flexible adjustment, and the third priority load is the cooling load that allows for reduction and / or peak shifting; wherein, the first priority load is allocated preferentially within the scheduling cycle, and the second and third priority loads are adjusted under the premise of meeting preset comfort constraints or process constraints.

3. The cooling cluster collaborative scheduling method according to claim 1, characterized in that, The building quota data packet also includes a data packet identifier, a generation timestamp, an energy efficiency lower limit, and a standby redundancy ratio; the device control data packet also includes a parent data packet identifier, a target execution interval, a receipt requirement flag, and an idempotency flag; the building control layer and the device terminal layer perform deduplication processing on duplicate data packets based on the idempotency flag.

4. The cooling cluster collaborative scheduling method according to claim 1, characterized in that, The device execution control quantity includes at least one of the compressor target frequency, valve target opening degree and / or water pump target flow rate; the device terminal layer converts the load share into the device execution control quantity according to a preset mapping relationship, and applies ramp-up restrictions to the device execution control quantity to limit the change range of control quantity between adjacent time periods.

5. The cooling cluster collaborative scheduling method according to claim 1, characterized in that, The device control data packets corresponding to the first priority load are set to require a receipt; the preset receipt time limit is 2 seconds, and the number of retransmissions is 2; if no status receipt is received after the number of retransmissions is reached, the building control layer removes the unreceived device from the candidate device set and executes the degradation strategy.

6. The cooling cluster collaborative scheduling method according to claim 5, characterized in that, The degradation strategy includes at least one of the following: activating standby equipment in standby mode; reducing the cooling share of the third priority load to release cooling redundancy; and performing restricted flexible adjustment on the second priority load.

7. The cooling cluster collaborative scheduling method according to claim 1, characterized in that, The preset triggering condition includes at least one of the following: the deviation between the actual load and the predicted load exceeds 10%; The device returned an error code; The supply deviation of the first priority load exceeds a preset deviation threshold; the incremental rescheduling includes: screening the set of affected buildings whose deviation contribution exceeds a preset threshold, screening the set of affected equipment whose load rate exceeds a preset load threshold or has an abnormal state, and using the decision result of the previous scheduling cycle as the initial solution to recalculate the control allocation for the set of affected buildings and the set of affected equipment.

8. A cooling cluster collaborative scheduling system, characterized in that, It includes a regional control module, a building control module, an equipment terminal module, and a communication module; - The area control module is configured to collect cooling demand information of each building and operating status information of each device, and generate building quota data packets; The building control module is configured to receive the building quota data packet, generate the device control data packet, and perform receipt confirmation, timeout retransmission, duplicate data packet deduplication, and downgrade processing after retransmission failure based on the status receipt. The device terminal module is configured to map load shares to device execution control variables, execute control, and return status feedback; and The area control module and / or building control module are further configured to perform incremental rescheduling on the affected set of buildings and set of equipment when a preset trigger condition is met.

9. The refrigeration cluster collaborative scheduling system according to claim 8, characterized in that, The communication module includes a first communication link and a second communication link. The first communication link is used to transmit building quota data packets between the area control module and the building control module. The second communication link is used to transmit equipment control data packets and status receipts between the building control module and the equipment terminal module. Both the building control module and the equipment terminal module maintain a set of processed data packet identifiers to avoid repeatedly executing the same control command.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it causes the processor to perform the cooling cluster collaborative scheduling method according to any one of claims 1 to 7.

Images