Air source heat pump cooperative peak regulation method based on master-slave architecture block chain network

Abstract

The invention provides an air source heat pump cooperative peak shaving method based on a master-slave architecture block chain network. The method circularly executes the following steps that a main chain divides all child nodes into at least two slave chains based on a same-temperature-area chain building mechanism; each slave chain determines an anchor node in each sub-node contained in the slave chain and accesses the main chain; each slave chain dynamically adjusts a block output period based on a peak regulation state index, and each slave chain distributes a received power grid peak regulation task to each child node at the beginning of each block output period, and performs consensus block output based on a weighted PBFT consensus mechanism at the end of each block output period; and after the main chain performs consensus block generation on any slave chain, the main chain releases the power grid peak regulation task to the slave chain again based on the newly generated consensus block. According to the technical scheme, the main chain can be driven from bottom to top to adjust peak regulation control and effective information recording precision based on the condition that the states of local areas where different slave chains are located change drastically.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of new energy intelligent peak shaving and blockchain application, and specifically provides an air source heat pump collaborative peak shaving method based on a master-slave architecture blockchain network. BACKGROUND

[0002] Air source heat pumps are widely promoted in the fields of residential heating, commercial hot water and industrial waste heat recovery due to their high efficiency and energy saving characteristics. In recent years, the system scale and user-side installed capacity have achieved rapid growth. However, the peak shaving capability of air source heat pump clusters is highly dependent on the real-time fluctuations of external environmental temperature and building group heat demand. At the same time, the large-scale access of renewable energy makes the balance of power supply and demand more challenging, and the peak shaving mode gradually evolves from traditional single adjustment on the "source" side to collaborative response on the "source, load" sides. With the growth of electricity side load and distributed air source heat pump cluster scale, distributed air source heat pump clusters participating in power grid peak shaving puts higher requirements on real-time scheduling capability. However, traditional centralized scheduling often has difficulty in obtaining and processing the operation data of distributed devices in a timely manner, and lacks collaborative scheduling and conflict resolution mechanisms across regions and aggregators, resulting in low peak shaving efficiency.

[0003] Blockchain technology has been widely introduced into the field of energy scheduling due to its characteristics of decentralization, tamper resistance and traceability. The existing blockchain in the energy scene adopts fixed block period and unified consensus weight, which cannot balance the real-time and efficiency of air source heat pump systems, and also cannot encourage high-performance nodes to prioritize block generation. At the same time, the existing blockchain in the energy scene also lacks fine-grained sharding in collaborative scheduling across regions and multiple merchants, making it difficult to strike a good balance between effectively recording operational information and avoiding redundant data.

[0004] In summary, in the cross-application field of air source heat pump cluster grid peak shaving and blockchain data management, there is an urgent need for an overall solution that can not only meet real-time data chaining, but also efficiently coordinate multi-region task allocation based on the energy output and peak shaving characteristics of air source heat pumps, and store high-value information in a targeted manner. SUMMARY

[0005] In order to solve the problems existing in the prior art, the application provides an air source heat pump collaborative peak shaving method based on a master-slave architecture blockchain network, which includes a master chain in the upper layer and a plurality of sub-nodes in the lower layer. The master chain includes a master node corresponding to the power dispatching department, and each sub-node corresponds to an air source heat pump cluster.

[0006] During the execution of the method, the following steps are cyclically executed: S1, the master chain divides all sub-nodes into at least two slave chains based on the same temperature zone chain building mechanism; S2, each slave chain determines an anchor node from the respective sub-nodes contained in its interior and accesses the master chain, the anchor node being used to enable communication between the master chain and the respective slave chain; S3, each slave chain performs dynamic adjustment of the block cycle based on the peak-shaving state indicator, and At the beginning of each block cycle of each slave chain, the received grid peak-shaving tasks are allocated to the respective sub-nodes of the slave chain based on the peak-shaving capabilities of the respective sub-nodes of the slave chain, and at the end of each block cycle of each slave chain, the grid peak-shaving task completion of the respective sub-nodes of the slave chain in the current block cycle and the initial scheme of the grid peak-shaving of the next block cycle are consensus-blocked based on the weighted PBFT consensus mechanism; After any slave chain performs consensus-blocking, the master chain re-issues the grid peak-shaving tasks to the slave chain based on the newly generated consensus block.

[0007] The air source heat pump collaborative peak-shaving method based on the master-slave architecture blockchain network provided by the embodiments of the present application divides the air source heat pump cluster nodes across aggregators into slave chains of the same temperature zone by adopting the same temperature zone chain building mechanism, builds the master-slave blockchain architecture from bottom to top, realizes localized consistent scheduling, and eliminates cross-domain conflicts. At the same time, based on three indicators of the environmental temperature change rate, the sensitivity of performance to temperature, and the building group heat demand fluctuation rate, the block generation period is dynamically calculated and adjusted, the block cycle is shortened when the temperature in the local area suddenly changes, the master chain is driven to perform more fine peak-shaving control on the area, and key data lagging is effectively avoided. The block chain is uploaded, while in the stable period, the block generation period is extended to reduce redundancy. In addition, the node peak-shaving capability and historical peak-shaving contribution are also included in the consensus voting weight, which encourages the nodes to actively improve their peak-shaving capabilities, improves the overall peak-shaving capability of the system, and forms a self-optimizing collaborative peak-shaving network. BRIEF DESCRIPTION OF DRAWINGS

[0008] Figure 1 A flowchart of the air source heat pump collaborative peak-shaving method based on the master-slave architecture blockchain network provided by the embodiments of the present application is provided. Figure 2 A regional distribution diagram of air source heat pump clusters under the jurisdiction of different aggregators in one embodiment is provided. Figure 3 A schematic diagram of the architecture of the master-slave architecture blockchain network formed after a plurality of slave chains are established according to the same temperature zone chain building mechanism in one embodiment is provided. Figure 4 A specific flowchart of step S3 in one embodiment is provided. Figure 5 A ledger structure diagram of the sub-nodes and master node of each slave chain in one embodiment is provided. Figure 6 A variation diagram of the number of blocks for grid peak-shaving using scheme one in one specific embodiment is provided. Figure 7 In one embodiment, the variation of the number of blocks for grid peak shaving using scheme two is shown in the following diagram. Figure 8 In one embodiment, the variation of the number of blocks for grid peak shaving using scheme three is shown in the following diagram. DETAILED DESCRIPTION

[0009] The application will be further described below based on the preferred embodiments and with reference to the accompanying drawings.

[0010] In the description of the embodiments of the application, it should be noted that if the terms "upper", "lower", "inner", "outer" and the like indicate the orientation or positional relationship shown in the drawings, or the orientation or positional relationship in which the product of the embodiments of the application is usually placed, and are only used to facilitate the description of the application and simplify the description, and therefore cannot be understood as indicating or implying that the device or element must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as limiting the application. In addition, in the description of the application, in order to distinguish different units, the first, second and the like are used in the description, but these are not limited by the order of manufacture, and cannot be understood as indicating or implying relative importance, and the name may be different in the detailed description and the claims of the application. In addition, in order to facilitate understanding, the various components on the drawing are enlarged or reduced, but this practice is not intended to limit the scope of protection of the application.

[0011] The terms in the specification are used to illustrate the embodiments of the application, but are not intended to limit the application. It should be noted that, unless otherwise specified and limited, if the terms "provided", "connected", "connected" appear, they should be understood in a broad sense, for example, they can be fixedly connected, or detachably connected, or integrally connected; can be mechanically connected, can be directly connected, or indirectly connected through an intermediate medium, can be connected inside two elements. For those skilled in the art, the specific meaning of the above terms in the application can be specifically understood.

[0012] The embodiments of the application provide an air source heat pump cooperative peak shaving method based on a master-slave architecture blockchain network, wherein the master-slave architecture blockchain network comprises a master chain located in an upper layer and a plurality of sub-nodes located in a lower layer, the master chain comprises a master node corresponding to a power dispatching department, and each sub-node corresponds to an air source heat pump cluster.

[0013] In some specific embodiments, various blockchain engines / platforms known to those skilled in the art can be used to build a two-layer blockchain system with a master-slave architecture and perform operations such as system node registration and initialization. For example, the FISCO BCOS platform can be used. The platform comes with a development-friendly Turing-complete smart contract (compatible with Ethereum Solidity contracts), a PBFT consensus mechanism (Practical Byzantine Fault Tolerance) that can be selected, and a standard multi-round voting consensus block generation method can be implemented. The master chain-slave chain mode can also be realized through multi-chain + relay / bridge splicing.

[0014] Furthermore, the main chain layer serves as a scheduling layer and only includes one main chain. After the power dispatching department completes the node registration, the node corresponding to the power dispatching department is first merged into the main chain as the main node, and the peak-shaving demand information of the upper level is obtained through the power dispatching department.

[0015] The chain layer serves as the execution layer and contains multiple registered sub-nodes. Each sub-node corresponds to an air source heat pump cluster at a specific location. These air source heat pump clusters can come from one aggregator, or from two or even more different aggregators.

[0016] In addition, as a blockchain system with a two-layer architecture, both the main chain layer and the slave chain layer need to deploy smart contracts and clients accordingly to collect the relevant operating and environmental data in real time, and perform peak-shaving task (contract) generation and recording, consensus block generation and other operations.

[0017] like Figure 1 As shown, during the implementation of this method, the following steps are cyclically performed: S1: The main chain divides all child nodes into at least two slave chains based on the isothermal zone chain building mechanism; S2, each slave chain determines an anchor node from each of its sub-nodes and connects to the main chain. The anchor node is used to enable communication between the main chain and each slave chain; S3, each slave chain dynamically adjusts the block generation period based on the peak-shaving status indicator, and At the beginning of each block generation cycle, each slave chain allocates the received power grid peak-shaving tasks to each of its child nodes based on the peak-shaving capabilities of each child node of the slave chain. At the end of each block generation cycle, a consensus is reached on the completion status of the power grid peak-shaving tasks of each child node in the current block generation cycle and the initial power grid peak-shaving plan for the next block generation cycle based on the weighted PBFT consensus mechanism. After the main chain reaches consensus on any slave chain and generates a block, it will re-issue the power grid peak-shaving task to the slave chain based on the newly generated consensus block.

[0018] The steps S1 to S3 are described in detail below in combination with the drawings and specific embodiments.

[0019] Step S1 is used to divide all the sub-nodes in the chain layer into at least two slave chains, Figure 2 It is shown that in one specific embodiment, the location distribution of each air source heat pump cluster included in a double-layer blockchain and the corresponding aggregator are shown, and in this embodiment, the air source heat pump clusters corresponding to each sub-node belong to two aggregators (aggregator 1 and aggregator 2), wherein the air source heat pump clusters under the jurisdiction of aggregator 1 are represented by black squares, and the air source heat pump clusters under the jurisdiction of aggregator 2 are represented by black circles. As shown in the figure, the air source heat pump clusters under the jurisdiction of the two aggregators show a cross-distribution phenomenon in region B. Since the air temperature is different in different regions, the energy output characteristics of the air source heat pumps at the corresponding positions are different, and the peak shaving capabilities are also different, so different peak shaving strategies may be needed for the air source heat pump clusters in different regions. However, if a unified scheduling method is used for the air source heat pump clusters under the jurisdiction of the same aggregator, scheduling conflicts may occur, for example, when aggregator 1 schedules all the air source heat pump clusters under its jurisdiction to perform peak cutting tasks, and aggregator 2 schedules all the air source heat pump clusters under its jurisdiction to perform valley filling tasks, then in region B, they will cancel each other out, causing wasted work. Therefore, in the embodiments of the present application, the main chain divides all the sub-nodes into at least two slave chains based on the isothermal zone chain building mechanism.

[0020] The isothermal zone chain building mechanism is a principle proposed by the present application for constructing slave chains in view of the fact that the number of air source heat pump clusters included by different aggregators is different and spans different temperature zones. The core idea is to consider that air source heat pump clusters with similar temperatures are likely to be concentrated in a certain location and perform similar grid peak shaving tasks, so the air source heat pump clusters of different aggregators are re-chained according to the temperature conditions, and the size of each slave chain is constrained, so that each slave chain only includes air source heat pump clusters with similar temperature ranges and the number of nodes does not exceed the upper limit (which can cross aggregators), thereby effectively utilizing the peak shaving capabilities of each slave chain and avoiding waste of peak shaving capabilities.

[0021] In some preferred embodiments, step S1 further comprises the following steps: S11, obtaining the predicted temperature of all sub-nodes at a preset time, and sorting all sub-nodes based on the predicted temperature to obtain a sorted sequence of sub-nodes.

[0022] Specifically, the predicted temperature of all sub-nodes at a future preset time can be obtained by querying or calling a weather prediction model through the Internet, and then sorted in ascending or descending order to obtain a sorted sequence of sub-nodes.

[0023] The preset time can be obtained by counting the historical temperature of the area covered by all the child nodes, for example, in some preferred embodiments, the preset time can include at least one of the following: the statistical value of the lowest temperature time in each day and night, and the statistical value of the highest temperature time in each day and night. At the above two time points, the energy output and peak shaving capacity of the air source heat pump cluster have the greatest difference, so they are used as the basis for dividing the slave chain, which can effectively improve the temperature consistency of the air source heat pump cluster in each slave chain, and is beneficial to unified scheduling of the air source heat pump cluster in each slave chain to cooperatively perform the grid peak shaving task.

[0024] Since the above-mentioned preset time will change with the passage of time as the seasons change (for example, as the sunrise time changes, the lowest temperature in summer may occur at 4-5 am, and in winter it may occur at about 6-7 am), therefore, a more preferred re-chaining method is to regenerate the slave chain at least at the above-mentioned two preset times in each day and night, that is, steps S1 to S3 will be executed at least twice in each day and night.

[0025] In addition, in some preferred embodiments, each slave chain also obtains the real-time temperature of all child nodes in it in real time, and if the standard deviation of the actual temperature of all child nodes in any slave chain exceeds the preset recombination threshold (such as 2-4°C), it indicates that the temperature in the area where the child nodes of the slave chain are located has fluctuated greatly before the originally scheduled preset time. In this case, the regeneration of the slave chain in step S1 can be automatically triggered. Obviously, in this case, the predicted temperature of the preset time as the basis for sorting can be the predicted temperature of a time close to the current time, for example, the predicted temperature of each child node in the next two hours or one hour, to ensure that each slave chain is always aggregated based on the latest temperature trend.

[0026] S12, a slave chain is newly created as the current slave chain.

[0027] S13, if the sorting sequence of the child node is empty, the step S1 is ended, otherwise the first child node in the sorting sequence of the child node is extracted; S14, if the difference between the predicted temperature of the extracted child node and the average predicted temperature of all child nodes in the current slave chain does not exceed the node merging temperature difference threshold, and the number of child nodes in the current slave chain does not reach the upper limit of the number of nodes, step S15 is executed, otherwise step S12 is returned; S15, the extracted child node is merged into the current slave chain, and then step S13 is returned.

[0028] Specifically, the merged temperature difference threshold and the upper limit of the number of nodes in each slave chain can be determined based on the number of all child nodes and the climatic conditions in the areas covered by all child nodes. For example, in some plain areas, the temperature difference between different locations is not much different, so the merged temperature difference threshold can be set to a smaller value, such as 1°C or 1.5°C. Otherwise, the merged temperature difference threshold can be increased. For another example, if the scale of each aggregator is small, the upper limit of the number of nodes in each slave chain can be set to a smaller value, such as 30 or 50. Otherwise, the upper limit of the number of nodes can be increased.

[0029] After determining the merge temperature difference threshold and the upper limit of the number of nodes, steps S12 to S15 can be executed cyclically according to the isotropic chain building mechanism until all child nodes are added to a slave chain.

[0030] Each time a slave chain is regenerated in step S1, a connection between the master chain and the slave chain needs to be established. In the embodiment of the present application, this connection is achieved by determining an anchor node for each slave chain in step S2. Figure 3 Each slave chain includes an anchor node. At the same time, the anchor node is also connected to the upper-level main chain, thereby realizing data interaction between the main chain and each slave chain.

[0031] Preferably, the anchor node for each slave chain is determined through a weighted election mechanism, taking into account the representativeness (closeness to the average predicted temperature of the slave chain), reliability (historical number of times the predicted temperature of each child node has participated in peak shaving), and stability (the variance of historical temperature fluctuations of each child node). The closer the predicted temperature of a child node is to the average predicted temperature of the slave chain, the more representative it is of the overall situation of the slave chain as an anchor node. Similarly, the more times a child node has participated in peak shaving, the stronger its reliability is, and the smaller the variance of historical temperature fluctuations, the higher its stability is. Therefore, using these three factors as the conditions for determining anchor nodes, the selected anchor node will be representative, reliable, and stable, avoiding single points of failure and information silos, and achieving secure and reliable data synchronization under multi-chain collaboration.

[0032] In some specific embodiments, the smart contract at the slave layer can determine the anchor node weight of each child node in any slave chain based on the following formula: (1), in, For the child node in the slave chain The anchor node weight, For child nodes The predicted temperature, is the average predicted temperature of all child nodes in the slave chain, For child nodes The weight of the number of times of historical participation in peak load regulation, For child nodes the number of times of participating in peak regulation in history, an upper limit of the number of times of participating in peak regulation in history (indicating that the number of times of participating in peak regulation reaches the upper limit, the number of times of participating in peak regulation will not be increased the weight occupied), the historical temperature fluctuation variance of the child node (in some preferred embodiments, the historical temperature in the past 24 hours can be counted every hour, so that the value of the historical temperature fluctuation variance is obtained ), a stability adjustment coefficient for adjusting the influence of the historical temperature fluctuation variance on the weight, and the specific value can be determined by comprehensively considering the historical temperature data distribution characteristics of each child node and the stability requirement of the anchor node.

[0033] Further, the smart contract can determine the child node with the highest value in the chain as the anchor node responsible for data synchronization between the sub-chain and the main chain.

[0034] In some preferred embodiments, a number of standby anchor nodes can also be selected in order of from high to low, so that in the event of anchor node failure or failure, the anchor node function can be automatically replaced to ensure the stability of cross-chain communication and avoid single point failure. In other preferred embodiments, the smart contract can also monitor the health status of each anchor node, and when the health status check of the anchor node of a sub-chain fails, the anchor node is determined again by formula (1).

[0035] Step S3 is used to implement cross-chain peak regulation task scheduling of the air source heat pump cluster contained in each sub-chain, and consensus block and uplink of the peak regulation task completion, Figure 3 the embodiment shown illustrates a specific process of step S3.

[0036] Taking the sub-chain 1 in Figure 3 as an example (the block period thereof can be represented as ), at the beginning of each block period of the sub-chain 1 , the sub-chain 1 receives the grid peak regulation task from the main chain through the anchor node 1, and then distributes the grid peak regulation task to each child node of the sub-chain 1. Each child node executes the distributed grid peak regulation task, and before the end of the block period , the consensus block is generated based on the weighted PBFT mechanism.

[0037] Further, the newly generated consensus block is sent to the main chain through the anchor node 1, and after the main chain accepts the newly generated consensus block, the consensus block is appended to the ledger of the main chain. Meanwhile, the grid peak regulation task of the sub-chain 1 is updated based on the consensus block, and is sent to the sub-chain 1 through the anchor node 1, so as to complete the dynamic adjustment of the peak regulation task of the sub-chain 1.

[0038] Figure 4 from chain 2 to from chain The process of grid peak shaving and consensus block can refer to from chain 1, which will not be described here.

[0039] As analyzed in the foregoing, since each from chain is divided based on the predicted air temperature characteristics, the geographically dispersed air source heat pump cluster nodes affiliated to different aggregators can be dynamically divided into several temperature zone from chains according to the future predicted air temperature “from bottom to top”, ensuring localized consistent scheduling. In the process of grid peak shaving, different temperature zones may encounter different actual air temperature changes. In addition, different air source heat pump clusters have different unit heat efficiencies, and have different performance response characteristics under the same air temperature change. At the same time, the heat demand change of the heat load (such as buildings, workshops, etc.) supplied by the air source heat pump cluster will also affect the load of the air source heat pump cluster and cause the corresponding change of the peak shaving capacity of the air source heat pump cluster. Therefore, in some preferred embodiments, the block period of each from chain is bound with the air temperature change rate, the sensitivity of the performance of the air source heat pump cluster corresponding to each sub node to the air temperature, and the demand change rate of the heat load corresponding to each sub node.

[0040] In some specific embodiments, for any one from chain, the block period is determined based on the following formula: (2), wherein, is the block period of the from chain (for example, from chain 1, from chain 2, …, from chain The block periods of the from chain 1, the from chain 2, …, and the from chain , , …, ) can be respectively denoted as , is the lower limit and the upper limit of the block period, is the air temperature change rate of the sub node in the from chain, is the sensitivity of the performance of the air source heat pump cluster corresponding to the sub node to the air temperature, is the demand change rate of the heat load corresponding to the sub node , is the mean function, representing the mean value of the corresponding indicators of all sub nodes in the from chain in the current block period, is the maximum function, representing the maximum value of the corresponding indicators of all sub nodes in the from chain in the current block period, , , are the normalized air temperature change rate indicator, the sensitivity of the performance to the air temperature indicator, and the demand change rate of the heat load indicator, respectively, , , , , , , , are adjustment coefficients.

[0041] Specifically, the three indicators of the change rate of ambient temperature, the sensitivity of air source heat pump cluster unit thermal efficiency to temperature, and the change rate of heat load demand are reported by each sub-node in the chain through the smart contract periodically, and the reported data is stored on the chain after being summarized and verified by the smart contract. At the end of each block period, the block period is re-determined according to the latest three indicators, and the newly calculated block period is broadcast to all sub-nodes. After receiving the message, each sub-node will start the next round of consensus block and account update according to the new block period. In addition, any newly generated block of the slave chain will be actively pushed to the main chain through its anchor node, and after being verified by the main chain, the block will be recorded in the account of the main chain. That is, the account update of the main chain is driven by the account update of any slave chain.

[0042] As shown in the three slave chains and one main chain of Figure 5 , the consensus block of each sub-node of slave chain 1 is performed with a block period of , and the consensus block of each sub-node of slave chain 2 and slave chain 3 is performed with a block period of , , respectively. The account of the main chain is updated in response to the changes in the accounts of each slave chain, and the recorded blocks are shown at the bottom of Figure 5 .

[0043] As can be seen from Figure 5 , in the iterative block process, slave chain 1 has one or more of the three indicators fluctuate significantly, so after the consensus block 1-2 completes the block, the length of consensus block 1-3 and consensus block 1-4 is greatly shortened. By increasing the frequency of grid peak shaving operation and information recording of slave chain 1, the dynamic changes of each air source heat pump cluster load and peak shaving capacity of slave chain 1 can be responded to, the peak shaving strategy and task can be adjusted in time, and the local fluctuation of slave chain 1 can be accurately captured to record the effective information reflecting the system fluctuation at a higher frequency. At the same time, it avoids too frequent interference to other slave chains running smoothly and records a large amount of redundant data.

[0044] Returning to Figure 4 , the iterative block process of step S3 is continued to be described, as shown in the figure, in a complete block and task adjustment process, the slave chain and the main chain need to complete the following operations: ​(a) After the start of a new block generation cycle, the slave chain receives the updated grid peak-shaving tasks issued by the power dispatching department (master node) through the anchor node; (b) The smart contract of the slave chain comprehensively considers the peak-scaling capabilities of each sub-node to allocate peak-scaling tasks. For example, in some optional embodiments, for any slave chain, each of its sub-nodes can be allocated based on the following formula: The peak load shaving task of the power grid is allocated: (3), in, This is the power grid peak load shaving task received by the slave chain in the new block generation cycle. 、 Sub-nodes 、 Rated power, 、 Node 、 The proportion of available power, For all child nodes in the chain Perform accumulation operation, For child nodes The peak-shaving task assigned in the new block generation cycle.

[0045] (c) Execute the assigned peak-shaving tasks from each child node of the chain; (d) The slave chain reaches consensus and produces a block at the end of the block production cycle; In the embodiment of the present application, any consensus block generated within a slave chain is used to record and form a consensus on the completion of the power grid peak-shaving task of the slave chain in the current block generation cycle, as well as the initial power grid peak-shaving plan for the next block generation cycle. In addition, as mentioned above, the newly generated consensus block will be pushed to the main chain and drive the main chain to re-issue the power grid peak-shaving task to the slave chain.

[0046] Among them, in the embodiments of the present application, a weighted PBFT consensus mechanism is adopted for block generation operations. This mechanism introduces scalable peak capacity and historical contribution weights into the classic PBFT (Practical Byzantine Fault Tolerance) process, giving nodes with high scalable peak capacity and high historical contribution greater voting weights, and distributes incentives according to voting weights after a block is successfully generated, encouraging nodes to continuously improve their own performance and achieve efficient and self-optimizing consensus block generation from within the chain.

[0047] In some specific embodiments, for any one slave chain, at the beginning of each block cycle, each sub-node submits its adjustable peak capacity (the maximum available power that can be put in this round) in this block cycle to the smart contract, and the smart contract determines the PBFT weight of each sub-node based on the following formula: (4), wherein, is the PBFT voting weight of the sub-node , is the sum of the PBFT voting weights of all sub-nodes, is the proportion of the adjustable peak capacity of the sub-node in the current block cycle to the total adjustable peak capacity of all sub-nodes of the slave chain, is the proportion of the peak contribution of the sub-node in the last block cycle, reflecting the degree of continuous contribution, , , are the weights of , , respectively, , are the peak contribution amounts of the sub-nodes , in the last block cycle.

[0048] After determining the voting weight of each sub-node, each slave chain can perform a consensus block operation based on weighted PBFT at the end of each block cycle.

[0049] The PBFT consensus block mechanism generally includes five steps, namely, Request, Pre-Prepare, Prepare, Commit, and in addition, generally includes a Reply step. In the present application, since a double-layer master-slave multi-blockchain structure is adopted, the above steps need to be performed between different blockchains.

[0050] In some specific embodiments, for any one slave chain, the following operations are performed in the consensus block stage: First, the smart contract of the slave chain determines the power grid peak shaving task completion of the slave chain in this block cycle and the power grid peak shaving initial scheme of the slave chain in the next block cycle based on the power grid peak shaving task completion and the adjustable peak capacity broadcasted by each sub-node, and broadcasts to all sub-nodes of the slave chain. The above operation corresponds to the Request and Pre-Prepare stages.

[0051] In some specific embodiments, the smart contract can summarize the data reported by each child node to obtain the completion status of the power grid peak-shaving task of the slave chain in the current block cycle, and the initial power grid peak-shaving plan for the next block cycle can be determined based on the following formula: (5), in, This is the initial plan for peak load regulation of the power grid of the slave chain in the next block generation cycle (i.e., the new block generation cycle). The meanings of other variables have been introduced and will not be repeated here.

[0052] The second step is the Prepare phase. After verifying that the above broadcast is correct, each child node in the chain broadcasts the Prepare message to the blockchain network. When the sum of the weights in the Prepare messages received is greater than or equal to the preset weight ratio (for example, 2 / 3), the consensus of this phase is formed, and then the Commit phase is entered.

[0053] The third step is the Commit phase. When more than a preset weight ratio (e.g., 2 / 3) of the child nodes in the entire system broadcast the results of their own verification, a consensus is reached and the broadcast is sent again. Each child node broadcasts the submission message again.

[0054] Fourth, in the Reply phase, when the sum of the weights in the cumulatively received submission messages is greater than or equal to the preset weight ratio (e.g., 2 / 3), all nodes reach a consensus on the completion of peak-scaling for the current block cycle, the duration of the next block cycle, and the peak-scaling capacity. The above information and the adjusted block cycle information are packaged into a new consensus block, which is appended to the respective blockchain ledgers by each child node. At the same time, the new block is fed back to the main chain by the anchor node of the slave chain.

[0055] In some preferred embodiments, the slave chain's smart contract can also distribute block incentives according to the PBFT voting weight ratio of each child node to promote continuous participation and performance optimization.

[0056] (e) The master chain is in any slave chain (e.g. Figure 4 After the slave chain 1) reaches consensus and generates a block, the power grid peak-shaving task is re-issued to the slave chain based on the newly generated consensus block.

[0057] In some preferred embodiments, the master chain updates the grid peak-shaving task of the slave chain through the following steps: In the first step, the main chain’s smart contract evaluates the deviation between the predicted temperature of the slave chain in the next block cycle and the weighted optimal operating temperature to obtain a temperature difference index.

[0058] Specifically, the main chain can obtain the predicted temperature of each child node of the slave chain in the next block cycle through online query or calling the meteorological forecast model to obtain the predicted temperature of the slave chain in the next block cycle (for example, taking the average of the predicted temperatures of all child nodes in the next block cycle), and combine the optimal operating temperature of the air source heat pump cluster corresponding to each child node in the slave chain to calculate the temperature difference index between the two to measure the degree to which the environment deviates from the optimal operating conditions during the execution of the peak-shaving task.

[0059] For example, for any slave chain, the temperature difference index can be determined by the following formula: (6), in, is the weighted optimal operating temperature of the slave chain, For child nodes The optimal operating temperature, The predicted temperature of the slave chain in the next block generation cycle, It is the temperature difference index of the slave chain.

[0060] In the second step, the smart contract of the main chain constructs a composite attenuation factor based on the temperature difference indicator, and uses the composite attenuation factor to correct the initial grid peak-shaving plan of the slave chain in the next block cycle, thereby obtaining a grid peak-shaving task that is re-issued to the slave chain.

[0061] Specifically, the grid peak-shaving task of the slave chain can be re-determined based on the following formula: (7), The brackets in the above formula are composite attenuation factors, including exponential attenuation terms and high-order polynomial attenuation terms. 、 are the weights of the exponential decay term and the high-order polynomial decay term, To guarantee the minimum weight, 、 、 is the device temperature sensitivity coefficient, where 、 Used to adjust the decay rate, Used to control the penalty intensity of high-order polynomial attenuation terms at high temperature differences. Specific embodiment 1 To illustrate the dynamic adjustment of the peak shaving level and the efficient information recording capability of the "master-slave chain scheme based on adaptive block generation period" of the present application in the process of grid peak shaving participated by large-scale air source heat pump clusters, the present application carries out simulation verification through specific embodiment 1, and in this embodiment, the data timeliness and resource utilization of the scheme (scheme three) of the present application, the "master-slave chain scheme based on fixed block interval" (scheme one) and the "single chain scheme based on adaptive block generation period" (scheme two) are compared.

[0063] Specifically, as shown in Figure 6 , the following 6-hour comparative experiment is designed, wherein scheme one and scheme three are each composed of 3 slave chains and 1 master chain, each slave chain has a fixed block output of 4 blocks per hour under stable working conditions, and scheme two only includes a single chain.

[0064] When temperature fluctuations of different degrees occur in any region, the settings of each scheme are as follows: Scheme one: master-slave chain based on fixed block interval, each slave chain always outputs blocks at a fixed rate of 4 blocks per hour under any working condition, and the master chain aggregates the number of blocks output by the 3 slave chains in the current period and has a fixed block interval of 12 blocks per hour, and the experimental results are as shown in Figure 6 .

[0065] Scheme two: single chain based on adaptive block generation period, all nodes are deployed on the same chain, and the block output is 12 blocks per hour under stable conditions; when there are large or small fluctuations in the temperature of any region, the entire chain accelerates the block output according to the maximum fluctuation amplitude of the entire network. When the entire network tends to be stable, the entire chain will reduce the block output speed. The experimental results are as shown in Figure 7 .

[0066] Scheme three: master-slave chain based on adaptive block generation period, each slave chain independently adjusts its block output frequency according to the temperature fluctuations in the region, and each slave chain pushes the block information to the master chain immediately after completing a block output. The master chain outputs blocks in the current period equal to the sum of the block outputs of the 3 slave chains in the current period. When the temperature in the region fluctuates or tends to be stable, each slave chain adjusts the block generation period dynamically according to the adaptive strategy. The experimental results are as shown in Figure 8 .

[0067] Table 1 lists the consensus block output conditions under the three schemes.

[0068] Table 1 Consensus block output conditions under the three schemes Through this embodiment, it can be seen that: Scheme one maintains a fixed block output frequency of 12 blocks per hour at any fluctuation stage and cannot respond to temperature mutations or load fluctuations; The second scheme triggers the whole chain to over-speed and block out when there are local fluctuations in any region, for example, the block out amount increases to 20 and 18 blocks at the 2nd hour and the 5th hour, which generates a large number of redundant blocks irrelevant to the actual local fluctuations, and causes the whole network performance and timeliness to be mismatched. The third scheme accelerates or delays the block out of the slave chain according to the actual situation of each slave chain, and can achieve the optimal balance of local response and global summary between actual fluctuations and global stability. For example, at the 2nd hour, the local region of the slave chain 1 fluctuates sharply, so only the slave chain 1 increases the block out speed from 4 blocks / hour to 8 blocks / hour due to the sharp fluctuation, and the main chain is 15 blocks in total, which saves the redundancy compared with the second scheme and accurately captures the local fluctuation, avoiding the lag of the key data uplink.

[0069] It can be seen that the scheme of the present application can adjust the block out frequency of the slave chain in a certain local region when the peak regulation situation fluctuates, drive the main chain to dynamically adjust the peak regulation task of the local region, and increase the recording frequency of effective information in the peak regulation process of the region. The slave chain of other regions remains stable, thereby avoiding the whole network redundant block out while ensuring the timely uplink of key data. When the corresponding region of a slave chain is stable, only the slave chain is slightly slowed down to further reduce the redundant block out. Thus, the superiority of the present application in improving data timeliness and reducing storage and computing overhead is achieved.

[0070] The above detailed the specific embodiments of the present application, and for those skilled in the art, without departing from the principles of the present application, the present application can be improved and modified in several ways, and these improvements and modifications also belong to the protection scope of the present application.

Claims

1. A collaborative peak-shaving method for air-source heat pumps based on a master-slave architecture blockchain network, wherein the master-slave architecture blockchain network includes a main chain at the upper layer and several sub-nodes at the lower layer. The main chain includes a master node corresponding to the power dispatching department, and each sub-node corresponds to an air-source heat pump cluster, characterized in that: The following steps are executed in a loop: S1: The main chain divides all child nodes into at least two slave chains based on the isothermal zone chain building mechanism; S2, each slave chain determines an anchor node from each of its sub-nodes and connects to the main chain. The anchor node is used to enable communication between the main chain and each slave chain; S3, each slave chain dynamically adjusts the block generation period based on the peak-shaving status indicator, and At the beginning of each block generation cycle, each slave chain allocates the received power grid peak-shaving tasks to each of its child nodes based on the peak-shaving capabilities of each child node of the slave chain. At the end of each block generation cycle, it reaches a consensus on the completion status of the power grid peak-shaving tasks of each child node in the current block generation cycle and the initial power grid peak-shaving plan for the next block generation cycle based on the weighted PBFT consensus mechanism. After the main chain reaches consensus on any slave chain and generates a block, it will re-issue the power grid peak-shaving task to the slave chain based on the newly generated consensus block.

2. The air source heat pump collaborative peak-shaving method based on the master-slave architecture blockchain network according to claim 1 is characterized in that: Step S1 includes the following steps: S11, obtaining the predicted temperature of all child nodes at a preset time, and sorting all child nodes based on the predicted temperature to obtain a sorting sequence of the child nodes; S12, create a new slave chain as the current slave chain; S13, if the sorted sequence of child nodes is an empty set, then end step S1, otherwise extract the current first child node from the sorted sequence of child nodes; S14: If the difference between the predicted temperature of the extracted child node and the average predicted temperature of all child nodes in the current slave chain does not exceed the node merging temperature difference threshold, and the number of child nodes in the current slave chain does not reach the upper limit of the number of nodes, then execute step S15; otherwise, return to step S12; S15, merge the extracted child nodes into the current slave chain, and then return to step S13.

3. The air source heat pump collaborative peak-shaving method based on the master-slave architecture blockchain network according to claim 2 is characterized in that: Steps S1 to S3 are executed at least twice in each day and night, and the preset time includes at least one of the following time periods: a statistical value of the lowest temperature time period in each day and night, and a statistical value of the highest temperature time period in each day and night.

4. The air source heat pump collaborative peak-shaving method based on the master-slave architecture blockchain network according to claim 2 is characterized in that: When the standard deviation of the real-time temperatures of all child nodes in any slave chain exceeds a preset reorganization threshold, step S1 is re-executed.

5. The air source heat pump collaborative peak-shaving method based on the master-slave architecture blockchain network according to claim 2 is characterized in that: For any slave chain, its anchor node is determined based on the following formula: ， in, 、 They are the The anchor node weights and predicted temperatures of the child nodes, is the average predicted temperature for this slave chain, For the slave chain The weight of the number of times a child node has participated in power grid peak regulation in history, For the slave chain The number of times a child node has participated in the peak load regulation of the power grid in history, The upper limit of the number of times the company has participated in peak load regulation in the past. For the slave chain The historical temperature fluctuation variance of each child node, is the stability adjustment factor.

6. The air source heat pump collaborative peak-shaving method based on the master-slave architecture blockchain network according to claim 1 is characterized in that: For any slave chain, its block generation period is determined based on the following formula: ， in, is the block generation period of the slave chain, , They are the lower and upper limits of the block generation period, For the child node in the slave chain The rate of temperature change, For child nodes The corresponding sensitivity of the air source heat pump cluster performance to the air temperature, For child nodes The corresponding rate of change of heat load demand, is the mean function, is the maximum value function, 、 、 They are the normalized temperature change rate index, the performance sensitivity index to temperature index, and the heat load demand change rate index. 、 、 They are 、 、 The weight of 、 is the adjustment coefficient.

7. The air source heat pump collaborative peak-shaving method based on the master-slave architecture blockchain network according to claim 6 is characterized in that: For any slave chain, at the beginning of each block generation cycle, the PBFT voting weight of each child node in the slave chain is determined based on the following formula: in, For child nodes PBFT voting weight, is the sum of the PBFT voting weights of all child nodes, Child nodes in the current block generation cycle The ratio of the peak-adjustable capacity of the slave node to the total peak-adjustable capacity of all child nodes in the slave chain, for The weight of 、 Sub-nodes 、 Rated power, 、 Node 、 The proportion of available power, For all child nodes in the chain Perform accumulation operation, For child nodes The percentage of peak load shaving completed in the last block generation cycle, for The weight of 、 Sub-nodes 、 The peak load contribution in the previous block generation cycle.

8. The air source heat pump collaborative peak-shaving method based on the master-slave architecture blockchain network according to claim 7 is characterized in that: For any slave chain, at the end of each block generation cycle, the completion status of the power grid peak-shaving tasks of each child node in the current block generation cycle and the initial power grid peak-shaving plan for the next block generation cycle are consensus-generated based on the weighted PBFT consensus mechanism. Specifically, The smart contract of the slave chain determines the completion status of the power grid peak-shaving task of the slave chain in the current block generation cycle and the initial power grid peak-shaving plan of the slave chain in the next block generation cycle based on the completion status of the power grid peak-shaving task and the peak-shaving capacity broadcast by each child node, and broadcasts it to all child nodes of the slave chain; All child nodes of the slave chain generate consensus blocks based on the PBFT consensus mechanism by performing multiple rounds of weighted voting and appending the generated consensus blocks to the blockchain ledgers of each child node. In the Prepare phase, Commit phase, and Reply phase, when the sum of the PBFT voting weights of the child nodes performing the broadcast exceeds the preset total weight ratio, a consensus is formed in each phase.

9. The air source heat pump collaborative peak-shaving method based on the master-slave architecture blockchain network according to claim 1 is characterized in that: After receiving the updated consensus block of any slave chain, the master chain determines the power grid peak-shaving task to be reissued to the slave chain through the following steps: The main chain's smart contract evaluates the deviation between the predicted temperature of the slave chain in the next block generation cycle and the weighted optimal operating temperature to obtain a temperature difference index; The smart contract of the main chain constructs a composite attenuation factor based on the temperature difference indicator, and uses the composite attenuation factor to correct the initial grid peak-shaving plan of the slave chain in the next block cycle, thereby obtaining a grid peak-shaving task that is re-issued to the slave chain.

10. The air source heat pump collaborative peak-shaving method based on the master-slave architecture blockchain network according to claim 9 is characterized in that: The grid peak load regulation task to be re-issued to the slave chain is determined based on the following formula: ， in, 、 They are the power grid peak-shaving task and the initial power grid peak-shaving plan received by the slave chain in the new block generation cycle, 、 Sub-nodes 、 Rated power, 、 are the weights of the exponential decay term and the high-order polynomial decay term, To guarantee the minimum weight, 、 、 is the device temperature sensitivity coefficient, For all child nodes in the chain Perform accumulation operation, is the weighted optimal operating temperature of the slave chain, For child nodes The optimal operating temperature, The predicted temperature of the slave chain in the next block generation cycle, It is the temperature difference index of the slave chain.

Images