Intelligent regulating valve cluster control method and system

Abstract

This application relates to an intelligent control method and system for a cluster of regulating valves. Multiple valves within a pipeline network are each configured with an edge node. These edge nodes collect local sensor data and upload feature data to a cloud-based collaborative layer. The cloud-based collaborative layer performs spatiotemporal fusion of the feature data from each edge node, identifies the global operating condition, and generates a cluster-level optimization strategy. The valves are divided into multiple valve groups based on the hydraulic coupling strength between them. Strategies are issued in batches to each valve group, ensuring synchronous switching of valves within the same group. After a valve group switches, the cloud-based collaborative layer marks the valve group that has not received all confirmation information within a preset confirmation window as a broken valve group. Only the broken valve group is reverted to its pre-switching operating state and re-enqueueed into subsequent switching batches, while maintaining the post-switching operating state of the remaining valve groups. This application enables pipeline network convergence when local obstruction occurs during cluster strategy switching.

Description

Technical Field

[0001] This application relates to the field of automatic control of pipeline valves, and in particular to an intelligent control method and system for regulating valve clusters. Background Technology

[0002] In fluid pipeline networks in scenarios such as chemical industrial parks and centralized heating systems, multiple regulating valves are typically installed. By adjusting the opening degree of each valve, the flow and pressure distribution at various points within the pipeline network can be controlled. When the operating conditions of the pipeline network change, such as load fluctuations, changes in user-side demand, or the commissioning or decommissioning of certain pipeline sections, it is often necessary to coordinate the adjustment of multiple valves distributed in different locations within the pipeline network to transition the network from its current state to a target state adapted to the new operating conditions.

[0003] As pipeline networks expand and operating conditions become more complex, relying solely on individual valves to independently adjust their openings locally is insufficient to handle global changes in operating conditions. Therefore, deploying edge nodes with computing capabilities at each valve location to collect local data and make preliminary decisions, while the cloud aggregates operational data from the entire pipeline network to grasp the overall operating conditions and generate optimized strategies for the entire valve cluster, which are then distributed to each valve for execution. This approach has become a way to improve the regulation capabilities of the pipeline network.

[0004] However, when the cluster-level optimization strategy generated in the cloud is deployed, multiple valves in the pipeline network need to switch to their respective target operating states. These switching actions are difficult to complete atomically and simultaneously at the edge nodes corresponding to each valve. During the transition period when some valves have switched while others have not, the pipeline network is in an intermediate state where the old and new operating states are mixed. The hydraulic coupling between the valves causes this intermediate state to induce oscillations in the pipeline network. Furthermore, when some valves cannot switch to the correct position according to the predetermined sequence due to actuator obstruction or other reasons, the switched valves and the valves that have not yet switched to the correct position are hydraulically mutually restrained. The cluster-level optimization strategy is unable to return to the stable state before the switch as a whole, nor can it advance to the target state as a whole. As a result, the pipeline network oscillates repeatedly between multiple intermediate states and is unable to converge to a stable state adapted to the new operating conditions. Summary of the Invention

[0005] In order to constrain transitional oscillations during cross-node switching of cluster-level optimization strategies, and to ensure that the remaining valve groups converge to their respective target operating states and the pipeline network converges to an achievable stable operating condition even when the switching of some valves is obstructed, this application provides an intelligent regulating valve cluster control method and system.

[0006] Firstly, this application provides an intelligent control method for a cluster of regulating valves, which adopts the following technical solution: A method for intelligent control of a cluster of regulating valves, comprising multiple valves installed in a pipeline network, each valve having an edge node, including: S1. Each edge node collects local sensing data at the corresponding valve, performs preprocessing and preliminary decision-making on the local sensing data, and uploads the feature data to the cloud collaboration layer; S2. The cloud collaboration layer performs spatiotemporal fusion on the feature data of multiple edge nodes, identifies the global operating conditions, and generates a cluster-level optimization strategy based on the global operating conditions; S3. When the cloud collaboration layer issues the cluster-level optimization strategy to switch the operating status of each valve, it divides the multiple valves into multiple valve groups according to the hydraulic coupling strength between each valve. The hydraulic coupling strength between each valve in the same valve group is higher than the hydraulic coupling strength between different valve groups. S4. The cloud collaboration layer issues the cluster-level optimization strategy on the basis of the valve group, so that each valve in the same valve group is synchronously switched to the target operating state determined by the cluster-level optimization strategy, and different valve groups are switched in batches. S5. After each valve group is switched, the edge node corresponding to each valve in the switched valve group sends back the effective confirmation information to the cloud collaboration layer. The cloud collaboration layer records the valve group that has not received all the effective confirmation information in the preset confirmation window as the broken valve group, only rolls the broken valve group back to the running state before the switch, keeps the running state of the other valve groups that have been switched, and re-schedules the broken valve group into the subsequent switching batch.

[0007] By adopting the above technical solution, the cluster-level optimization strategy is distributed in batches, grouping valves with similar hydraulic coupling strength into groups and distributing them as valve groups. This allows strongly coupled valves to switch synchronously within the same valve group, while weakly coupled valve groups switch sequentially between each other, thus confining the transitional oscillations caused by non-atomic activation across nodes within the valve group. Furthermore, activation confirmation information identifies broken valve groups that have not completed atomic switching within a preset confirmation window. A rollback command is issued to the broken valve group while maintaining the operating status of the remaining switched valve groups. The broken valve group is then reordered into subsequent batches, with broken valve groups that can respond to the rollback command reverting to their pre-switching state. The operating status of the valve group is monitored. The broken valve group that cannot respond due to the complete failure of the actuator remains at its current actual opening and is isolated. The cloud collaboration layer then uses the current actual state of the broken valve group as the baseline to re-estimate the hydraulic coupling strength of the remaining valves that have not yet switched and regroups them. This allows the remaining parts of the pipeline network to remain in a converged state without relying on the valve group itself to be able to move when a valve group cannot be in position due to the obstruction of the actuator. This avoids the overall retreat or overall advancement of the cluster strategy. Thus, even when the local switching is obstructed, the remaining valve groups can still converge to their respective target operating states, and the pipeline network can converge to an achievable stable operating condition.

[0008] Optionally, in step S5, the cloud collaboration layer also records valve groups whose deviation between the actual opening degree of the valve after switching and the target opening degree corresponding to the target operating state exceeds a preset opening degree tolerance as broken valve groups; when the cloud collaboration layer re-arranges the broken valve groups into subsequent switching batches, it uses the operating state after switching of the remaining valve groups that have completed switching as a baseline to re-estimate the hydraulic coupling strength between each valve in the broken valve group, and determines the switching order of the broken valve groups after rearrangement based on the re-estimated hydraulic coupling strength.

[0009] By adopting the above technical solution, in addition to whether the effective confirmation information has been collected, the deviation between the actual opening degree and the target opening degree is further used as the defect criterion, so that the situation where the valve has returned confirmation but has not actually arrived is also included in the defect handling; and during the rearrangement, the hydraulic coupling strength is re-estimated based on the operating status of the other valve groups after switching, so that the rearrangement order of the defective valve groups is adapted to the current pipeline network status.

[0010] Optionally, among the multiple valve groups, the valve group that flows first along the pipeline is denoted as the upstream valve group, and the valve group that flows last is denoted as the downstream valve group. When the edge node corresponding to each valve in the downstream valve group detects a change in local hydraulic parameters, it autonomously triggers a local operating state switch. In S4, the hydraulic disturbance caused by the switching of the upstream valve group is transported to the downstream valve group through the pipeline with a transport time lag. The cloud collaboration layer determines the arrival time of the hydraulic disturbance to the downstream valve group based on the propagation time of the hydraulic disturbance from the upstream valve group to the downstream valve group through the pipeline, and suppresses the local operating state switch autonomously triggered by the edge node corresponding to each valve in the downstream valve group due to the hydraulic disturbance during the arrival time.

[0011] By adopting the above technical solution, for the case where the downstream edge node has the local autonomous switching capability, the time period when the hydraulic disturbance caused by the upstream switching reaches the downstream is used as the suppression window. During this period, the autonomous switching triggered by the downstream edge node misjudging the passing hydraulic disturbance as a change in local operating conditions is suppressed, so as to avoid the upstream and downstream switching being superimposed under the influence of time lag and aggravating the transition state fluctuation.

[0012] Optionally, in S4, when each valve in the same valve group gradually changes from its current opening to the target opening corresponding to the target operating state, the opening of each valve changes along a pre-calibrated opening change trajectory. The combination of the intermediate openings of each valve in the valve group on the opening change trajectory makes the pipeline network meet the preset hydraulic constraints. The preset hydraulic constraints include that the pressure of each node in the pipeline network is within a preset pressure range and there is no backflow in the pipeline network.

[0013] By adopting the above technical solution, not only are the start and end states of valve group switching constrained, but also the intermediate opening combinations it passes through during the gradual change process. This ensures that the pressure at each node of the pipeline network along the entire trajectory of the valve group from the current opening to the target opening is within the allowable range and there is no backflow, thus avoiding instantaneous overpressure or backflow during the linkage and gradual change of valves in the same group.

[0014] Optionally, the hydraulic coupling strength between each valve varies with the flow distribution of the pipeline network; in S4, before issuing the next batch of valve groups, the cloud collaboration layer re-estimates the hydraulic coupling strength of each valve that has not yet been switched based on the regrouping status reflecting the switching effect of the issued batch, and re-divides the valve groups of the valves that have not yet been switched according to the re-estimated hydraulic coupling strength.

[0015] By adopting the above technical solution, considering that the hydraulic coupling strength changes with the flow distribution of the pipeline network, the coupling strength between valves that have not yet been switched is re-evaluated and regrouped based on the switching effect of the previously issued batches before the subsequent batches are issued, so that the grouping of the subsequent batches matches the actual pipeline network status after the switching of the previous batches.

[0016] Optionally, the regrouping state is a predicted state. The cloud collaboration layer uses the pipeline hydraulic model to forward extrapolate the state that the pipeline will reach after the switching of the current batch of valve groups is completed, and uses this as the predicted state. Before the switching of the current batch of valve groups is completed, the valve groups of the valves that have not yet been switched are regrouped according to the predicted state.

[0017] By adopting the above technical solution, the pipeline network status after the batch switching has been completed is used as the basis for regrouping based on the forward extrapolation of the pipeline network hydraulic model. This allows the grouping of the next batch to be determined in advance before the current batch has been switched, thus offsetting the impact of the time required for the regrouping loop to travel back and forth between the cloud and the edge on the distribution rhythm.

[0018] Optionally, when each edge node disconnects from the cloud collaboration layer, it independently runs a local decision model to maintain the basic regulation of the valve.

[0019] By adopting the above technical solution, when the edge node loses connection with the cloud, each edge node still maintains the basic adjustment of the valve based on the local decision model, so that the pipeline network remains basically controllable during the communication interruption.

[0020] Optionally, when the edge node is reconnected, the cloud collaboration layer adjusts the valve to the operating state corresponding to the current global operating condition according to the operating state offset during the disconnection of the edge node in a graded and gradual manner, and the graded step size decreases within a preset range as the operating state offset increases.

[0021] By adopting the above technical solution, after the edge node reconnects, it gradually returns to the global operating condition according to the state offset during its disconnection. The larger the offset, the smaller the step size of the step size, thus avoiding the introduction of new transitional oscillations by making large adjustments at the moment of reconnection.

[0022] Optionally, when there are multiple broken valve groups, the order of reverting and rearranging each broken valve group is sorted according to the hydraulic coupling strength between each broken valve group and the switched valve group.

[0023] By adopting the above technical solution, when multiple broken valve groups occur simultaneously, the order of their retreat and rearrangement is arranged according to the hydraulic coupling strength between each broken valve group and the switched valve group, so that those with stronger coupling effects are dealt with first.

[0024] Optionally, an upper limit can be set for the number of rearrangements for each valve group. When the upper limit is reached, automatic switching will stop and a prompt for manual intervention will be output.

[0025] By adopting the above technical solution, an upper limit is set for the number of automatic rerouting operations of the valve group. When repeated rerouting fails to complete the switching, the automatic switching stops and prompts for manual intervention, thus preventing the system from endlessly rerouting under abnormal operating conditions.

[0026] Optionally, the effectiveness confirmation information includes the actual opening degree of the valve and the local hydraulic parameters at the valve, and the atomicity is determined based on the actual opening degree and the local hydraulic parameters.

[0027] By adopting the above technical solution, the actual opening degree of the valve and the local hydraulic parameters are used together to form the effective confirmation information. Based on the comprehensive judgment of the two, it is determined whether the atomic switching of the valve group is broken, so that the failure identification takes into account both the execution position and the hydraulic response.

[0028] Optionally, the duration of the preset confirmation window is adaptively determined based on the number of valves in the valve group and the communication latency from the edge node to the cloud.

[0029] By adopting the above technical solution, the duration of the preset confirmation window can be adaptively adjusted according to the number of valves in the valve group and the communication delay from the edge node to the cloud, avoiding misjudgment of normal switching as broken due to an excessively short window or delay of broken processing due to an excessively long window.

[0030] Optionally, after the arrival period ends, or after the local hydraulic parameters of the edge nodes corresponding to each valve in the downstream valve group recover to the range before the disturbance, the suppression of the local operating state switching of the edge nodes corresponding to each valve in the downstream valve group is released.

[0031] By adopting the above technical solution, the suppression of downstream autonomous switching is lifted after the arrival period ends or the local hydraulic parameters of the downstream edge node recover to the range before the disturbance, so that the downstream node can promptly resume its response to changes in the actual local operating conditions after the disturbance has passed.

[0032] Optionally, the preset hydraulic constraints also include ensuring that the flow velocity in each pipeline does not exceed the preset upper limit of flow velocity and that cavitation does not occur at each of the valves.

[0033] By adopting the above technical solution, in addition to the pressure range and the absence of backflow, the upper limit of the flow velocity in each pipeline and the prevention of cavitation at the valve are further incorporated into the preset hydraulic constraints, so that the valve group's gradual trajectory can avoid both high flow velocity scouring and cavitation.

[0034] Optionally, the hydraulic coupling strength between the valves is estimated by the cloud-based collaborative layer based on the influence coefficient of the opening change of one valve on the pressure or flow rate at the other valve in historical operating data.

[0035] By adopting the above technical solution, the cloud collaboration layer extracts the influence coefficient of the change in the opening of one valve on the pressure or flow at another valve from historical operating data, and estimates the hydraulic coupling strength between valves without relying on an accurate pipeline model.

[0036] Optionally, the hydraulic coupling strength between the valves is obtained by the cloud-based collaborative layer calculating the sensitivity of the opening change of one valve to the pressure or flow rate at the other valve based on the pipeline hydraulic model.

[0037] By adopting the above technical solution, the cloud collaboration layer calculates the sensitivity of the change in the opening of one valve to the pressure or flow at another valve based on the pipeline hydraulic model, thereby determining the hydraulic coupling strength between valves. This is suitable for scenarios where a relatively accurate pipeline model is already available.

[0038] Optionally, the order in which different valve groups are switched in batches is determined according to the hydraulic transition settling time caused by the switching of each valve group, wherein the valve group with a longer hydraulic transition settling time is switched before the valve group with a shorter hydraulic transition settling time.

[0039] By adopting the above technical solution, the switching order between valve groups is arranged according to the hydraulic transition settlement time caused by the switching of each valve group, so that the valve group with slower settlement can be switched earlier to obtain more sufficient settlement time.

[0040] Optionally, the valves at the boundary of two adjacent valve groups are referred to as boundary valves. During the switching process, the boundary valves are placed in a passivation state to limit the rate of change of the opening of the boundary valves. After the switching is completed, the passivation state of the boundary valves is released.

[0041] By adopting the above technical solution, the boundary valves at the boundary of adjacent valve groups are placed in a passivated state during switching to limit their opening change rate and reduce the mutual penetration of the switching action of adjacent valve groups through the boundary valves.

[0042] Secondly, the intelligent control valve cluster control system provided in this application adopts the following technical solution: A smart regulating valve cluster control system includes a cloud collaboration layer and multiple edge nodes, with multiple valves installed in a pipeline network and each valve configured with an edge node; Each of the aforementioned edge nodes is configured to collect local sensor data corresponding to the valve, perform preprocessing and preliminary decision-making on the local sensor data, and upload the feature data to the cloud collaboration layer; The cloud collaboration layer is configured to perform spatiotemporal fusion of the feature data of multiple edge nodes, identify global operating conditions, and generate cluster-level optimization strategies based on the global operating conditions. The cloud collaboration layer is also configured to, when issuing the cluster-level optimization strategy to switch the operating state of each valve, divide the multiple valves into multiple valve groups according to the hydraulic coupling strength between each valve. The hydraulic coupling strength between valves within the same valve group is higher than the hydraulic coupling strength between different valve groups. The cluster-level optimization strategy is issued on a per-valve-group basis, so that each valve within the same valve group switches synchronously to the target operating state determined by the cluster-level optimization strategy, and different valve groups switch in batches. The edge nodes corresponding to each valve in each valve group are also configured to send back effective confirmation information to the cloud collaboration layer after switching. The cloud collaboration layer is also configured to record valve groups that have not received all the effective confirmation information in a preset confirmation window as broken valve groups, only to revert the broken valve groups to the operating state before switching, maintain the post-switching operating state of the other valve groups that have completed switching, and re-schedule the broken valve groups into subsequent switching batches.

[0043] By adopting the above technical solution, the system uses edge nodes configured on each valve to undertake local data acquisition and preliminary decision-making, cloud-based collaborative layer to undertake global operating condition identification and cluster strategy generation, and valve groups to switch in batches. It also uses effective confirmation information to drive selective rollback and rearrangement of broken valve groups. In terms of hardware configuration, it achieves the technical effect of the above-mentioned intelligent regulating valve cluster control method, which enables the pipeline network to converge to an achievable stable operating condition even when local switching is blocked.

[0044] Optionally, the cloud collaboration layer is further configured to record valve groups whose deviation between the actual opening degree of the valve after switching and the target opening degree corresponding to the target operating state exceeds a preset opening degree tolerance as broken valve groups, and when the broken valve groups are re-arranged into subsequent switching batches, the hydraulic coupling strength between each valve in the broken valve group is re-estimated based on the operating state after switching of the remaining valve groups that have completed switching, and the switching order of the broken valve groups after rearrangement is determined according to the re-estimated hydraulic coupling strength.

[0045] By adopting the above technical solution, the system supplements the defect determination with the actual opening deviation in addition to the effective confirmation information, and determines the rearrangement order by re-estimating the coupling strength based on the new baseline when rearranging the defective valve group.

[0046] Optionally, among the multiple valve groups, the valve group that flows first along the pipeline is denoted as the upstream valve group, and the valve group that flows last is denoted as the downstream valve group. The edge nodes corresponding to each valve in the downstream valve group are configured to autonomously trigger a local operating state switch when a change in local hydraulic parameters is detected. The cloud collaboration layer is also configured to determine the arrival time of the hydraulic disturbance to the downstream valve group based on the propagation time of the hydraulic disturbance caused by the switching of the upstream valve group through the pipeline from the upstream valve group to the downstream valve group, and to suppress the local operating state switch autonomously triggered by the edge nodes corresponding to each valve in the downstream valve group due to the hydraulic disturbance during the arrival time.

[0047] By adopting the above technical solution, the system suppresses the autonomous handover triggered by upstream disturbances during the arrival period of downstream edge nodes with local autonomous handover capabilities, thereby reducing the superposition of upstream and downstream handovers under time delay.

[0048] Optionally, the cloud collaboration layer is further configured to cause the opening of each valve in the same valve group to change along a pre-calibrated opening change trajectory when the valves in the same valve group gradually change from their current opening to the target opening corresponding to the target operating state. The combination of the intermediate openings of each valve in the valve group on the opening change trajectory makes the pipeline network meet the preset hydraulic constraints. The preset hydraulic constraints include that the pressure of each node in the pipeline network is within a preset pressure range and there is no backflow in the pipeline network.

[0049] By adopting the above technical solution, the system ensures that each intermediate opening combination of valves in the same valve group meets the preset hydraulic constraints during the gradual change process, thus avoiding overpressure or backflow in the pipeline during the linkage gradual change.

[0050] In summary, this application includes at least one of the following beneficial technical effects: 1. This application groups valves with similar hydraulic coupling strength into a group and switches them in batches as valve groups. This constrains the transitional oscillations caused by the non-atomic activation of the cluster strategy across nodes within the valve group. After the valve group is switched, the failure valve group is identified by the activation confirmation information. A rollback command is issued to the failure valve group, so that the failure valve group that can respond rolls back to the operating state before the switch. The failure valve group that cannot respond due to the complete failure of the actuator remains at the current actual opening and is isolated. At the same time, the operating state of the other switched valve groups is maintained and the failure valve groups are rearranged. This allows the pipeline network to remain in a converged state without relying on the valve group's own ability to operate when a valve group cannot reach its position due to the obstruction of the actuator. When the local switch is obstructed, the other valve groups are still made to converge to their respective target operating states, and the pipeline network is made to converge to an achievable stable operating condition.

[0051] 2. This application supplements the defect determination with the deviation of the actual opening from the target opening and re-estimates the hydraulic coupling strength based on the new baseline during the rearrangement. It suppresses the autonomous switching of downstream edge nodes during the hydraulic disturbance arrival period and constrains each intermediate opening combination to meet the hydraulic constraints of pressure range and no backflow during the gradual change of the valve group. This further reduces the network fluctuations during the switching process in terms of defect identification, time delay processing and transition trajectory.

[0052] 3. In the process of issuing cluster strategies, this application dynamically re-estimates the hydraulic coupling strength of valves that have not yet been switched based on the switching effect of the batches that have been issued and regroups them. Furthermore, the regrouping is completed in advance based on the predicted state of the pipeline hydraulic model to offset the cloud-edge round-trip delay of the regrouping loop itself, so that the group division evolves in real time with the pipeline state and does not lag behind the batch switching process. Attached Figure Description

[0053] Figure 1 This is a schematic diagram of the intelligent regulating valve cluster control system according to an embodiment of this application; Figure 2 This is a flowchart illustrating the intelligent regulating valve cluster control method according to an embodiment of this application; Figure 3 This is a schematic diagram of the transition curve of pipeline pressure deviation over time in an embodiment of this application; Figure 4 This is a flowchart illustrating the time-delay gating process in the embodiments of this application; Figure 5 This is a schematic diagram showing the relationship between the pressure trajectory of the pipeline node caused by the change in valve opening in this embodiment of the application and the feasible region of the preset hydraulic constraints; Figure 6 This is a schematic diagram of the selective rollback and rearrangement of the defective valve group in an embodiment of this application.

[0054] Explanation of reference numerals in the attached figures: 10. Cloud-based collaborative layer; 20. Edge nodes; 30. Intelligent regulating valves; 40. Pipeline network. Detailed Implementation

[0055] The present application will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of the application and are not intended to limit the scope of the application.

[0056] This application discloses an intelligent control method for a cluster of regulating valves.

[0057] This method involves grouping multiple intelligent regulating valves in the same pipeline network according to their hydraulic coupling strength, switching their operating states in batches by valve group, and collecting confirmation information after each batch switch. Only valve groups that failed to confirm their switching are rolled back, while the remaining valve groups maintain their completed switching. This constrains transitional oscillations during cross-node switching of the cluster-level optimization strategy and ensures that the remaining valve groups converge to their respective target operating states even when some valve switching is obstructed, ultimately leading to a stable operating condition for the pipeline network. First, edge nodes at each valve collect local sensor data and upload features. Then, the cloud-based collaborative layer integrates the global operating conditions, generates a cluster-level optimization strategy, and distributes the switching in batches by valve group. Finally, after the switch, selective rollback and rearrangement of broken valve groups are performed based on confirmation information. This reduces pressure and flow oscillations caused by batch switching in multi-valve collaborative regulation and ensures that the pipeline network converges to a stable operating condition even when individual valve groups fail to reach their positions due to execution obstruction. The following section provides a detailed explanation of the terminology, main process flow, specific implementation of confirmation and selective rollback, and corresponding control system.

[0058] For ease of understanding, the core technological entities involved in this application will be defined first. For example... Figure 1As shown, the intelligent regulating valve cluster control system of this application embodiment includes a cloud collaboration layer 10, multiple edge nodes 20, and multiple intelligent regulating valves 30 installed in the pipeline network 40. Each intelligent regulating valve 30 is configured with a corresponding edge node 20. The intelligent regulating valve 30 is an actuator installed in the pipeline network 40, capable of continuously adjusting its own opening degree according to instructions to change the flow capacity of its respective pipeline. Multiple intelligent regulating valves 30 work collaboratively to form a valve cluster. The edge node 20 is a computing unit configured near each intelligent regulating valve 30, responsible for local sensor data acquisition and preliminary decision-making. The cloud collaboration layer 10 is a computing and decision-making unit that communicates with each edge node 20 and is responsible for global operating condition identification and cluster-level optimization strategy generation. The pipeline network 40 is a network of interconnected pipelines and nodes for fluid transport. A change in the opening degree of one valve will affect the pressure and flow rate of the pipelines containing other valves through pipeline coupling. The strength of this mutual influence is characterized in this application by the hydraulic coupling strength. Local sensor data refers to the pressure, flow rate, velocity, liquid level, and opening degree feedback measurements collected by edge node 20 at its corresponding valve. After performing preprocessing and preliminary decision-making on the local sensor data, edge node 20 uploads the extracted feature data to the cloud collaboration layer 10. Global operating conditions refer to the overall operating status of the pipeline network identified by the cloud collaboration layer 10 based on the feature data of multiple edge nodes 20. Cluster-level optimization strategies refer to the adjustment schemes generated by the cloud collaboration layer 10 based on global operating conditions, which include the target opening degree of each valve and its switching batches and switching sequences.

[0059] The flow chart of the intelligent regulating valve cluster control method in this application embodiment is as follows: Figure 2 As shown, it includes steps S1 to S5.

[0060] In S1, each edge node collects local sensor data at its corresponding valve. After collection, the edge node performs preprocessing on the local sensor data, including one or more of the following: filtering, outlier removal, and normalization, to suppress measurement noise and outliers from interfering with subsequent judgments. The edge node then performs preliminary decision-making on the preprocessed local sensor data. Preliminary decisions may include determining whether there is a pressure exceedance or flow abnormality at the current valve based on local thresholds, or making predictions about short-term trends based on local time series, thus achieving rapid identification of abnormal states locally. The edge node uploads the feature data on which the preliminary decision is based or extracted to the cloud collaboration layer. The feature data has been dimensionality reduced and cleaned relative to the original measurements, allowing the cloud collaboration layer to grasp the operating status of each valve without having to send back all the original measurements point by point.

[0061] In S2, the cloud-based collaboration layer performs spatiotemporal fusion on feature data uploaded from multiple edge nodes. This fusion, based on the topological distance of each valve within the pipeline network, their flow direction relationships, and the temporal sequence of feature data, correlates the dispersed individual valve states with the overall operational state of the pipeline network, thereby identifying the global operating condition. Examples include the network being under high load, experiencing sudden changes in local demand, or a branch line being blocked. The cloud-based collaboration layer generates cluster-level optimization strategies based on the identified global operating condition. These strategies include the target valve opening degree required to achieve the desired operating condition, as well as the switching batches and timing of valves switching to the target opening degree. When identifying the global operating condition, the cloud-based collaboration layer can use methods such as feature data state classification or clustering to categorize the current state into preset operating condition categories. Both methods use feature data as input and a global operating condition identifier as output; the difference lies in that the former determines the condition based on pre-defined operating condition boundaries, while the latter self-organizes and categorizes based on the distribution structure of the feature data.

[0062] In some embodiments, considering the possibility of communication link interruption between edge nodes and the cloud collaboration layer, each edge node independently runs a local decision model to maintain basic regulation of the corresponding valve when it detects a disconnection from the cloud collaboration layer. For example, the edge node determines the connection interruption through heartbeat timeout, and the local decision model maintains the valve opening within a preset safety adjustment range based on local sensor data. This ensures that the valve can maintain basic flow and pressure regulation even when the cloud-based cluster-level optimization strategy is lost, preventing loss of regulation capability due to communication interruption.

[0063] After the edge node re-establishes its connection with the cloud collaboration layer, the cloud collaboration layer, based on the offset of the valve's operating state during the edge node's disconnection period relative to the current global operating condition, re-aligns the valve to the operating state corresponding to the current global operating condition using a graded gradual change method. Graded gradual change breaks down a single state transition into several progressively approximating stages. The larger the total offset of the operating state, the more stages are required, and the smaller the single-stage opening adjustment step. This allows for more and finer stages to suppress hydraulic disturbances introduced by the re-alignment process when the total offset is large, and for fewer stages to converge quickly when the total offset is small.

[0064] In S3, before issuing cluster-level optimization strategies to switch the operating status of each valve, the cloud-based collaboration layer first divides multiple valves into multiple valve groups based on the hydraulic coupling strength between them. This ensures that the hydraulic coupling strength between valves within the same group is higher than the hydraulic coupling strength between different valve groups. Specifically, the cloud-based collaboration layer constructs a coupling strength matrix based on the hydraulic coupling strength between each pair of valves. Based on this matrix, valves with high coupling strength are grouped together, while valves with low coupling strength are grouped into different groups. This allows valves with strong mutual influence within the same group to switch synchronously, while valves with weak mutual influence between groups can be switched in batches. The number of groups is a trade-off in practical applications: too few groups result in too many valves to be synchronized within a group and limited vibration suppression benefits from staggered switching between groups; too many groups result in too many batches and increased overall switching time. The hydraulic coupling strength between each valve is not directly measurable but is estimated by the cloud-based collaboration layer based on the pipeline network's operating information.

[0065] In some embodiments, the hydraulic coupling strength between valves is estimated by the cloud-based collaboration layer based on historical operating data. Specifically, the cloud-based collaboration layer extracts the corresponding changes in pressure or flow at one valve when the opening of one valve changes from the historical operating data. The ratio of these two changes characterizes the hydraulic coupling strength between the two valves; a larger response ratio indicates a stronger impact of the adjustment of the former valve on the pipeline containing the latter valve. Since this estimation relies only on accumulated historical measurement data and does not require physical modeling of the pipeline network, it can still be implemented when the pipeline network structure is complex or the parameters are difficult to obtain accurately.

[0066] In other embodiments, the hydraulic coupling strength between valves is calculated by the cloud-based collaborative layer based on the pipeline network hydraulic model. The pipeline network hydraulic model describes the constraint relationship between pressure at each node and flow rate at each pipe segment using the nodal continuity equation and pipe segment resistance characteristics. The cloud-based collaborative layer calculates the change in pressure or flow rate at one valve caused by a small change in the opening of one valve, thus characterizing the hydraulic coupling strength between the two valves by the sensitivity at that point. Compared to estimation based on historical data, the hydraulic model-based method does not require waiting for the accumulation of historical operating conditions and can directly calculate the coupling strength for new operating conditions not yet appearing in historical data. This method is suitable for situations where pipeline network parameters are relatively complete and a reliable hydraulic model can be established. The historical data-based estimation method is suitable for situations where pipeline network modeling is difficult but historical operating data is sufficient. The two methods can be chosen based on the pipeline network conditions.

[0067] In S4, the cloud-based collaboration layer issues cluster-level optimization strategies on a valve group basis. For the same valve group, the cloud-based collaboration layer synchronizes the switching of all valves within the group to the target operating state determined by the cluster-level optimization strategy. This means issuing switching commands to all valves in the group within the same batch and aligning their actions in time, so that valves with strong mutual influence within the group complete their opening changes as simultaneously as possible, reducing mutual disturbances caused by sequential actions within the group; for example... Figure 3 As shown, for different valve groups, the cloud-based coordination layer switches them in batches, that is, the next valve group is sent out after the previous valve group has been switched and stabilized. This staggers the valve groups with weak mutual influence in time and avoids the superposition of disturbances caused by multiple groups switching at the same time. Figure 3 The curves are schematic and are used to qualitatively illustrate the effect of batch switching of valve groups on suppressing transient oscillations compared to simultaneous switching of multiple groups. The vertical axis represents the deviation of pipeline pressure from the target operating condition, and the horizontal axis represents the time after switching. The curves in the figure do not represent quantitative data from specific experiments or simulations.

[0068] In some embodiments, such as Figure 4 As shown, the valve group preceding the flow direction along the pipeline in a series of valve groups is designated as the upstream valve group, and the valve group following is designated as the downstream valve group. When the edge nodes corresponding to each valve in the downstream valve group detect changes in local hydraulic parameters, they can autonomously trigger a local operating state switch to respond locally to the changes in pipeline status. However, the hydraulic disturbance caused by the switching of the upstream valve group in S4 is transported to the downstream valve group via the pipeline network. This transport is not instantaneous but involves a transport lag. If the downstream edge nodes misinterpret this hydraulic disturbance propagated from the upstream switching as a necessary downstream adjustment and autonomously trigger a switch, the effect will be superimposed on the upstream switching, exacerbating the transitional oscillation. Therefore, the cloud-based collaborative layer determines the arrival time of the hydraulic disturbance in the downstream valve group based on the propagation time of the hydraulic disturbance from the upstream valve group to the downstream valve group via the pipeline network, and suppresses the autonomous local operating state switch triggered by the edge nodes corresponding to each valve in the downstream valve group due to this hydraulic disturbance within the arrival time. The propagation time can be estimated based on the pipe length between upstream and downstream valve groups, the flow velocity within the pipe, the propagation speed of pressure waves in the pipeline, and the topological path connecting the upstream and downstream. This determines the expected time window for the hydraulic disturbance to reach the downstream. By suppressing the downstream's autonomous switching triggered by the hydraulic disturbance within this time window, the downstream does not respond to the transient disturbance caused by the upstream switching and resumes autonomous regulation after the disturbance has passed, thus avoiding the superposition of time delays between upstream and downstream switching.

[0069] Furthermore, after the arrival period ends, or after the local hydraulic parameters of the edge nodes corresponding to each valve in the downstream valve group have recovered to the range before the disturbance, the cloud collaboration layer releases the suppression of the local operation state switching of the edge nodes corresponding to each valve in the downstream valve group, so that the downstream edge nodes can resume their autonomous response to the actual local adjustment needs, and avoid the suppression lasting too long and delaying the downstream adjustment to the real operating condition changes.

[0070] In some embodiments, during S4, when each valve in the same valve group gradually changes from its current opening to the target opening corresponding to the target operating state, the opening of each valve changes along a pre-calibrated opening change trajectory. The opening change trajectory specifies a series of intermediate openings that each valve passes through as the switching progresses during the switching process. Its shape is, for example, a piecewise linear or smooth S-shaped gradual change, preventing the valve from directly jumping from its current opening to the target opening. Figure 5 As shown in the figure, the horizontal axis represents the switching progress of the valve from its current opening to the target opening, and the vertical axis represents the pressure of the corresponding pipeline node. The area between the preset upper and lower pressure limits is the feasible region that satisfies the preset hydraulic constraints. The switching progress is the current opening of the corresponding valve at the starting point and the target opening of the corresponding valve at the ending point. The cloud-based collaborative layer pre-checks the opening change trajectory based on the established pipeline hydraulic model. That is, it takes the intermediate opening combinations on the opening change trajectory as input and calculates the corresponding node pressure and flow direction of each pipe segment through the pipeline hydraulic model. This ensures that the intermediate opening combinations of each valve in the valve group satisfy the preset hydraulic constraints, which include the pressure of each node in the pipeline being within the preset pressure range and the absence of backflow in the pipeline. Therefore, the switching process not only meets the final state requirements, but each intermediate opening falls within the acceptable operating range of the pipeline, avoiding infeasible transition states such as pressure exceeding limits or flow reversal during the gradual change. Figure 5 As shown, when the valve switches along the verified opening change trajectory, the pressure of the pipeline node falls within the feasible region throughout the entire switching process from the current opening to the target opening; however, the pressure of the pipeline node corresponding to the direct switching without verification falls outside the lower limit of the feasible region in the middle of the switching process, that is, it is lower than the preset pressure lower limit, resulting in the risk of backflow.

[0071] Furthermore, the preset hydraulic constraints, in addition to ensuring that the pressure at each node is within a preset pressure range and that there is no backflow in the pipeline, may also include that the flow velocity in each pipeline does not exceed a preset upper limit, and that cavitation does not occur at each valve. Including the upper limit of flow velocity in the constraint can prevent excessively high flow velocities in a certain pipeline due to intermediate opening combinations, which could cause erosion or water hammer. Including the constraint of preventing cavitation at valves requires that the pressure at the valve is higher than the vaporization pressure of the local fluid at the corresponding temperature, with a margin, to avoid cavitation bubbles caused by excessively low local pressure at the valve during the transition. The cloud-based collaborative layer verifies the above constraints when checking the opening change trajectory, ensuring that each intermediate opening combination passed through during the switching process simultaneously meets multiple operational limitations such as pressure, backflow, flow velocity, and cavitation.

[0072] In some embodiments, the hydraulic coupling strength between valves varies with the flow distribution in the pipeline network. Therefore, the grouping obtained based on the initial flow distribution may no longer reflect the current coupling relationship after several batches of valve groups have been switched. To address this, in S4, before issuing the next batch of valve groups, the cloud-based collaboration layer re-estimates the hydraulic coupling strength of each valve that has not yet been switched, based on the regrouping status reflecting the switching effect of the previously issued batches, and re-groups the valves that have not yet been switched according to the re-estimated hydraulic coupling strength. In this way, each batch of grouping is based on the flow distribution changed by the switched valves, ensuring that the intra-group synchronization and inter-group staggering of subsequent batches always match the current actual coupling relationship, rather than using outdated groupings from before the switch.

[0073] Furthermore, the aforementioned regrouping state can be a predicted state. The cloud-based collaborative layer utilizes the pipeline hydraulic model, taking the current pipeline state and the switching commands of the currently issued batch of valve groups as input, to forward extrapolate the state the pipeline will reach after the switching of this batch of valve groups is completed, and uses the extrapolated state as the predicted state; then, before the switching of the currently issued batch of valve groups is completed, the valve groups of the valves that have not yet been switched are regrouped according to the predicted state. Since the regrouping loop involves round-trip communication between the edge nodes and the cloud-based collaborative layer, there is a time delay. If regrouping is performed after the actual completion of this batch of switching and the return of measurement data, the issuance of the next batch will be delayed by this delay. However, by regrouping in advance based on the predicted state, the grouping decision of the next batch and the physical switching of this batch can proceed in parallel in time. The extrapolation advance offsets the round-trip delay of the regrouping loop, allowing the batch switching to be continuously connected without being interrupted by waiting for the return of measurement data.

[0074] In some embodiments, the order in which different valve groups are switched in batches is determined by the hydraulic transition settling time caused by the switching of each valve group. Valve groups with longer hydraulic transition settling times are switched before those with shorter hydraulic transition settling times. The hydraulic transition settling time refers to the time it takes for the pressure and flow rate measurements of a valve group to return to the steady-state zone after switching. By switching the valve group with the longer settling time first, its longer transition process is more sufficiently staggered with the switching of subsequent valve groups, avoiding the superposition of the transition state before settling and the new switching disturbance.

[0075] In other embodiments, the valves at the boundary between two adjacent valve groups are referred to as boundary valves. During switching, the boundary valves are placed in a passivation state to limit their opening rate of change, and the passivation state of the boundary valves is released after the switching is completed. Boundary valves are affected by the switching of two adjacent groups simultaneously, and their rapid changes in opening can easily transmit disturbances between groups. Limiting the opening rate of the boundary valves during switching can make the transition at the boundary smoother and weaken the disturbance coupling between adjacent groups through the boundary valves. After the switching is completed, the passivation is released to restore their normal regulating capability.

[0076] like Figure 6 As shown in step S5, after each valve group is switched, the cloud-based collaboration layer determines whether each valve group has been switched to the correct position based on the returned confirmation information. It only rolls back the valve groups that are not yet in position, while maintaining the switching results of the remaining valve groups that are already in position. Specifically, S5 includes sub-steps S51 to S54: S51. After the switch, the edge nodes corresponding to each valve in the valve group send back confirmation information to the cloud collaboration layer. The confirmation information indicates whether the valve has reached the target operating state. This feedback allows the cloud collaboration layer to grasp the actual implementation of the switch group by group, which serves as the input for subsequent defect determination.

[0077] S52. The cloud collaboration layer will record valve groups that have not received all effective confirmation information within the preset confirmation window as defective valve groups. Using the receipt of confirmation information within the confirmation window as a criterion, valve groups that have not completed the switch as expected can be identified promptly without needing to diagnose the cause of failure one by one, allowing for differentiated handling in S53. In some embodiments, the defect determination, in addition to whether the confirmation window has received all confirmation information, also considers the deviation between the actual opening degree and the target opening degree of the valve after the switch; that is, when the actual opening degree... relative to target opening satisfy (in, When setting the opening tolerance, the valve group to which the valve belongs is recorded as a defective valve group, so that it can still be identified even if the confirmation information has been returned but the valve has not actually been adjusted.

[0078] S53. The cloud-based collaboration layer issues a rollback command to the faulty valve group, causing it to revert to its pre-switching operating state while maintaining the post-switching operating state of the remaining valve groups that have already been switched. Specifically, for valve groups that are faulty due to communication confirmation failure or partial obstruction of the actuator but can still respond to the rollback command, they revert to their pre-switching operating state according to the command. For valve groups that cannot respond to the rollback command due to complete actuator failure, the cloud-based collaboration layer does not require them to perform further actions but instead keeps them at their current actual opening and isolates them from this batch of adjustments. This differentiated handling uses the fault determination result as input and the rollback or isolation of the faulty group and the maintenance of the remaining groups as output, ensuring that the obstruction of switching for some valve groups does not affect the valve groups that have already been successfully switched.

[0079] S54. The cloud-based collaboration layer will re-arrange the defective valve group into the subsequent switching batch, so that it can re-attempt the switching in the subsequent batch. The re-arranged defective group, as a valve that has not yet been switched, participates in the issuance and grouping of subsequent batches. Its switching result is also subject to the effective confirmation and selective rollback in this section, forming a closed loop of batch-by-batch convergence.

[0080] The aforementioned selective partial rollback differs from the unified rollback or unified hold for a batch of switches: When a valve group becomes completely unresponsive due to actuator obstruction, relying on further actions to compensate for its opening deviation is physically impossible. In this case, the cloud-based coordination layer does not require the valve group to perform any further actions. Instead, it maintains the post-switch operating state of the remaining valve groups without rolling back with the affected group and isolates or rearranges the broken valve group to subsequent actions independent of its current execution result. Simultaneously, the cloud-based coordination layer uses the current actual state of the broken valve group as a baseline to re-estimate the hydraulic coupling strength of the remaining valves that have not yet been switched and re-divides the valve groups. Thus, the convergence of the pipeline network is not contingent on the availability of the actuators of the broken valve group. The remaining valve groups still converge to their respective target operating states, and the pipeline network converges to a stable operating condition achievable under the current actual state of the broken valve group.

[0081] To facilitate understanding of the above mechanism, three scenarios are described. When all valve groups are confirmed in the confirmation window, no valve group is deemed defective, and each valve group retains its post-switching state; the switch is completed in one operation. When a single valve group is defective, only that group is reverted or isolated and rearranged, while the switching results of the remaining valve groups are retained. The pipeline converges after the group is re-switched in the next batch. When multiple valve groups are defective, each defective group is reverted or isolated and rearranged, while the remaining groups are retained. The pipeline gradually converges after several batches of rearrangement and re-switching.

[0082] In some embodiments, when the cloud-based collaborative layer in S5 re-includes the faulty valve group in the subsequent switching batch, it uses the post-switching operating state of the remaining valve groups that have already been switched as a baseline to re-estimate the hydraulic coupling strength between the valves in the faulty valve group, and determines the switching order of the faulty valve group after rearrangement based on the re-estimated hydraulic coupling strength. Since the remaining valve groups have been switched and the flow distribution of the pipeline network has changed accordingly, the coupling relationship between the faulty valve groups has changed under the changed flow distribution compared to before the switch. By re-estimating the coupling strength based on the post-switching state of the switched valve groups, the rearrangement grouping and rearrangement order of the faulty valve groups are established on the current actual coupling relationship, rather than using the coupling relationship before it was judged to be faulty, so that the re-switching after rearrangement is consistent with the current status of the switched valve groups.

[0083] When multiple broken valve groups exist, the cloud-based collaborative layer prioritizes the rollback and rearrangement of each broken valve group based on the hydraulic coupling strength between the broken valve group and the switched valve group. Broken valve groups with higher coupling strength to the switched valve groups are rolled back and rearranged first. This allows broken valve groups that have a greater impact on the switched valve groups to be addressed first, reducing the accumulation of mutual disturbances between multiple broken valve groups and between them and the switched valve groups during the rearrangement process.

[0084] As an optional implementation, the cloud-based collaboration layer sets a maximum number of rescheduling attempts for each valve group. When the number of rescheduling attempts for a valve group reaches this maximum, automatic switching for it is stopped and a prompt for manual intervention is output. Setting a rescheduling limit can prevent a valve group from being repeatedly rescheduled due to continuous actuator failure, thus avoiding unnecessary occupation of subsequent batches. It also ensures that when the automatic rescheduling capacity is exceeded, the handling authority is promptly transferred to manual intervention, preventing the automatic process from falling into an ineffective loop.

[0085] In some embodiments, the activation confirmation information includes the actual valve opening and the local hydraulic parameters at the valve. The cloud collaboration layer jointly determines whether the switch is defective based on the actual opening and the local hydraulic parameters. Local hydraulic parameters include, for example, the valve's pressure, flow rate, velocity, level, or opening feedback. Compared to using only whether the confirmation information is returned as a criterion, further verifying the actual opening and local hydraulic parameters can identify a defect even if the confirmation information has been returned but the pipeline hydraulic state has not reached the expected level, making the defect determination more consistent with the actual hydraulic effect of the switch. In embodiments combining the above multiple criteria, if any one of the following three conditions is met: not all activation confirmation information is received in the preset confirmation window, the deviation of the actual opening from the target opening exceeds the preset opening tolerance, or the local hydraulic parameters do not reach the expected level corresponding to the target operating state, the valve group is determined to be a defective valve group.

[0086] The duration of the preset confirmation window can be adaptively determined based on the number of valves in the valve group and the communication latency from the edge node to the cloud collaboration layer. The more valves there are and the greater the communication latency, the longer the window duration should be. If the confirmation window is too short, valve groups that are still in the normal feedback process will be misjudged as defective; if it is too long, it will delay the identification and rollback of truly defective valve groups. By adaptively determining the window duration in a positive correlation with the number of valves in the group and the communication latency, both timeliness and accuracy of the determination can be balanced under different valve group sizes and different communication conditions.

[0087] This application embodiment also provides an intelligent regulating valve cluster control system. The system includes a cloud collaboration layer 10 and multiple edge nodes 20. Multiple intelligent regulating valves 30 are installed in a pipeline network 40, and each intelligent regulating valve 30 is configured with a corresponding edge node 20. In this system, each edge node 20 collects local sensor data at its corresponding valve, performs preprocessing and preliminary decision-making on the local sensor data, and uploads the feature data to the cloud collaboration layer 10. The cloud collaboration layer 10 performs spatiotemporal fusion of the feature data from multiple edge nodes 20 to identify the global operating conditions and generate a cluster-level optimization strategy. When the cloud collaboration layer 10 issues a cluster-level optimization strategy to switch the operating state of each valve, it divides the multiple valves into multiple valve groups based on the hydraulic coupling strength between each valve, ensuring that the hydraulic coupling strength between valves within the same valve group is higher than the hydraulic coupling strength between different valve groups. The system issues cluster-level optimization strategies on a valve group basis, enabling valves within the same valve group to switch to the target operating state synchronously, and different valve groups to switch in batches. After each valve group switches, the edge nodes 20 corresponding to each valve in the switched valve group send back confirmation information to the cloud collaboration layer 10. The cloud collaboration layer 10 records valve groups that have not received all confirmation information within a preset confirmation window as broken valve groups, only reverting the broken valve groups to their pre-switching operating state, maintaining the post-switching operating state of the remaining valve groups that have completed the switch, and re-scheduling the broken valve groups into subsequent switching batches. The specific process of each component of the system implementing the above method steps can be found in the description of the corresponding method steps above, and will not be repeated here.

[0088] In this system, the cloud collaboration layer 10 also records valve groups whose deviation between the actual opening degree of the valve after switching and the target opening degree corresponding to the target operating state exceeds the preset opening degree tolerance as defective valve groups. When re-arranging defective valve groups into subsequent switching batches, the hydraulic coupling strength between each valve in the defective valve group is re-estimated based on the operating state after switching of the other valve groups that have completed switching. The switching order of the defective valve group after rearrangement is determined according to the re-estimated hydraulic coupling strength. The specific process corresponds to the description of defect determination extension and re-estimation rearrangement in the above method.

[0089] In this system, among multiple valve groups, the valve group that flows first along the pipeline is denoted as the upstream valve group, and the valve group that flows last is denoted as the downstream valve group. When the edge node 20 corresponding to each valve in the downstream valve group detects a change in local hydraulic parameters, it autonomously triggers a local operating state switch. The cloud collaboration layer 10 determines the arrival time of the hydraulic disturbance to the downstream valve group based on the propagation time of the hydraulic disturbance caused by the switching of the upstream valve group through the pipeline from the upstream valve group to the downstream valve group. During the arrival time, it suppresses the local operating state switch autonomously triggered by the edge node 20 corresponding to each valve in the downstream valve group due to the hydraulic disturbance. The specific process corresponds to the description of time-delay gating in the above method.

[0090] In this system, the cloud collaboration layer 10 also ensures that when the valves in the same valve group gradually change from their current opening to the target opening corresponding to the target operating state, the opening of each valve changes along a pre-calibrated opening change trajectory. Furthermore, it ensures that the combination of intermediate openings of each valve in the valve group on the opening change trajectory satisfies preset hydraulic constraints. The preset hydraulic constraints include that the pressure of each node in the pipeline network is within a preset pressure range and that there is no backflow in the pipeline network. The specific process corresponds to the description of the opening change trajectory and hydraulic constraints in the method above.

[0091] Those skilled in the art will understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the above system can be divided into different functional units or modules to complete all or part of the functions described above.

[0092] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for intelligent control of a cluster of regulating valves, wherein multiple valves are installed in a pipeline network, and each valve is configured with an edge node, characterized in that, include: S1. Each edge node collects local sensing data at the corresponding valve, performs preprocessing and preliminary decision-making on the local sensing data, and uploads the feature data to the cloud collaboration layer; S2. The cloud collaboration layer performs spatiotemporal fusion on the feature data of multiple edge nodes, identifies the global operating conditions, and generates a cluster-level optimization strategy based on the global operating conditions; S3. When the cloud collaboration layer issues the cluster-level optimization strategy to switch the operating status of each valve, it divides the multiple valves into multiple valve groups according to the hydraulic coupling strength between each valve. The hydraulic coupling strength between each valve in the same valve group is higher than the hydraulic coupling strength between different valve groups. S4. The cloud collaboration layer issues the cluster-level optimization strategy on the basis of the valve group, so that each valve in the same valve group is synchronously switched to the target operating state determined by the cluster-level optimization strategy, and different valve groups are switched in batches. S5. After each valve group is switched, the edge node corresponding to each valve in the switched valve group sends back the effective confirmation information to the cloud collaboration layer. The cloud collaboration layer records the valve group that has not received all the effective confirmation information in the preset confirmation window as the broken valve group, only rolls the broken valve group back to the running state before the switch, keeps the running state of the other valve groups that have completed the switch after the switch, and re-arranges the broken valve group into the subsequent switch batch.

2. The intelligent regulating valve cluster control method according to claim 1, characterized in that, In step S5, the cloud collaboration layer also records valve groups whose deviation between the actual opening degree of the valve after switching and the target opening degree corresponding to the target operating state exceeds the preset opening degree tolerance as broken valve groups. When the cloud collaboration layer re-arranges the broken valve groups into subsequent switching batches, it uses the operating state after switching of the remaining valve groups that have been switched as the baseline, re-estimates the hydraulic coupling strength between each valve in the broken valve group, and determines the switching order of the broken valve groups after rearrangement based on the re-estimated hydraulic coupling strength.

3. The intelligent regulating valve cluster control method according to claim 1, characterized in that, Among the multiple valve groups, the valve group that flows first along the pipeline is denoted as the upstream valve group, and the valve group that flows last is denoted as the downstream valve group. When the edge node corresponding to each valve in the downstream valve group detects a change in local hydraulic parameters, it autonomously triggers a local operating state switch. In step S4, the hydraulic disturbance caused by the switching of the upstream valve group is transported to the downstream valve group through the pipeline with a transport time lag. The cloud collaboration layer determines the arrival time of the hydraulic disturbance to the downstream valve group based on the propagation time of the hydraulic disturbance from the upstream valve group to the downstream valve group through the pipeline, and suppresses the local operating state switch autonomously triggered by the edge node corresponding to each valve in the downstream valve group due to the hydraulic disturbance during the arrival time.

4. The intelligent regulating valve cluster control method according to claim 1, characterized in that, In step S4, when each valve in the same valve group gradually changes from its current opening to the target opening corresponding to the target operating state, the opening of each valve changes along a pre-calibrated opening change trajectory. The combination of the intermediate openings of each valve in the valve group on the opening change trajectory makes the pipeline network meet the preset hydraulic constraints. The preset hydraulic constraints include that the pressure of each node in the pipeline network is within a preset pressure range and there is no backflow in the pipeline network.

5. The intelligent regulating valve cluster control method according to claim 1, characterized in that, The hydraulic coupling strength between each valve varies with the flow distribution of the pipeline network; in S4, before issuing the next batch of valve groups, the cloud collaboration layer re-estimates the hydraulic coupling strength of each valve that has not yet been switched based on the regrouping status reflecting the switching effect of the issued batch, and re-divides the valve groups of the valves that have not yet been switched according to the re-estimated hydraulic coupling strength.

6. The intelligent regulating valve cluster control method according to claim 5, characterized in that, The regrouping state is a predicted state. The cloud collaboration layer uses the pipeline hydraulic model to forward extrapolate the state that the pipeline will reach after the switching of the current batch of valve groups is completed, and uses this as the predicted state. Before the switching of the current batch of valve groups is completed, the valve groups of the valves that have not yet been switched are regrouped according to the predicted state.

7. An intelligent control system for a cluster of regulating valves, characterized in that, It includes a cloud collaboration layer and multiple edge nodes, with multiple valves installed in the pipeline network, and each valve is configured with one of the edge nodes; Each of the aforementioned edge nodes is configured to collect local sensor data corresponding to the valve, perform preprocessing and preliminary decision-making on the local sensor data, and upload the feature data to the cloud collaboration layer; The cloud collaboration layer is configured to perform spatiotemporal fusion of the feature data of multiple edge nodes, identify global operating conditions, and generate cluster-level optimization strategies based on the global operating conditions. The cloud collaboration layer is also configured to, when issuing the cluster-level optimization strategy to switch the operating state of each valve, divide the multiple valves into multiple valve groups according to the hydraulic coupling strength between each valve. The hydraulic coupling strength between valves within the same valve group is higher than the hydraulic coupling strength between different valve groups. The cluster-level optimization strategy is issued on a per-valve-group basis, so that each valve within the same valve group switches synchronously to the target operating state determined by the cluster-level optimization strategy, and different valve groups switch in batches. The edge nodes corresponding to each valve in each valve group are also configured to send back effective confirmation information to the cloud collaboration layer after switching. The cloud collaboration layer is also configured to record valve groups that have not received all the effective confirmation information in a preset confirmation window as broken valve groups, only to revert the broken valve groups to the operating state before switching, maintain the post-switching operating state of the other valve groups that have completed switching, and re-schedule the broken valve groups into subsequent switching batches.

8. The intelligent regulating valve cluster control system according to claim 7, characterized in that, The cloud-based collaboration layer is further configured to classify valve groups whose deviation between the actual opening degree of the valve after switching and the target opening degree corresponding to the target operating state exceeds a preset opening degree tolerance as broken valve groups. When the broken valve groups are re-arranged into subsequent switching batches, the hydraulic coupling strength between each valve in the broken valve group is re-estimated based on the operating state after switching of the remaining valve groups that have completed switching, and the switching order of the broken valve groups after rearrangement is determined according to the re-estimated hydraulic coupling strength.

9. The intelligent regulating valve cluster control system according to claim 7, characterized in that, Among the multiple valve groups, the valve group that flows first along the pipeline is denoted as the upstream valve group, and the valve group that flows last is denoted as the downstream valve group. The edge nodes corresponding to each valve in the downstream valve group are configured to autonomously trigger a local operating state switch when a change in local hydraulic parameters is detected. The cloud collaboration layer is also configured to determine the arrival time of the hydraulic disturbance to the downstream valve group based on the propagation time of the hydraulic disturbance caused by the switching of the upstream valve group through the pipeline from the upstream valve group to the downstream valve group, and to suppress the local operating state switch autonomously triggered by the edge nodes corresponding to each valve in the downstream valve group due to the hydraulic disturbance during the arrival time.

10. The intelligent regulating valve cluster control system according to claim 7, characterized in that, The cloud-based collaborative layer is also configured to cause the opening of each valve in the same valve group to change gradually from its current opening to the target opening corresponding to the target operating state, and the opening of each valve changes along a pre-calibrated opening change trajectory. The combination of the intermediate openings of each valve in the valve group on the opening change trajectory makes the pipeline network meet the preset hydraulic constraints. The preset hydraulic constraints include that the pressure of each node in the pipeline network is within a preset pressure range and there is no backflow in the pipeline network.

Images