A load prediction-based rolling optimization scheduling method for a pressure regulator

Abstract

This invention discloses a rolling optimization scheduling method for voltage regulators based on load forecasting, comprising: Step S1, a node registers and deploys a smart contract containing aggregation, compliance, and incentive rules on the blockchain; Step S2, the node forecasts the load based on a local model and uploads encrypted parameters to the blockchain; Step S3, the smart contract verifies the data, performs federated aggregation to generate a global forecast, and generates and issues scheduling instructions accordingly; Step S4, the node executes the instructions and adaptively adjusts by monitoring anomalies through situational awareness, and stores the execution feedback data on the blockchain; Step S5, the smart contract iteratively optimizes the model based on trusted on-chain data, calculates node contributions, allocates incentives, and synchronously updates the local model. This invention achieves privacy protection and trusted traceability of the entire scheduling process, ensuring "data does not leave the domain," and improves the automation, real-time performance, and robustness of scheduling decisions.

Description

Technical Field

[0001] This invention relates to the field of power automation technology, and in particular to a rolling optimization scheduling method for voltage regulators based on load forecasting. Background Technology

[0002] As a key regulating device in energy transmission and distribution systems, the operating status of voltage regulators directly affects system pressure stability, energy supply continuity, and overall operational safety. With the diversification of energy consumption structures and increasing load fluctuations, rolling optimization scheduling based on load forecasting has gradually become an important technical approach to improve the operating efficiency of voltage regulators. This type of method typically predicts load change trends and dynamically generates scheduling strategies accordingly, thereby achieving forward-looking adjustments to the operating parameters of voltage regulators.

[0003] However, in practical engineering applications, existing rolling optimization scheduling schemes for voltage regulators mostly rely on a unified scheduling decision-making mechanism. The scheduling center collects the operating data of nodes in various regions and then centrally completes predictive analysis and command generation. This technical model can meet basic requirements in scenarios with small scale or relatively stable load changes, but in complex systems with multi-region, multi-node collaborative operation and significant dynamic load changes, a series of unavoidable technical problems have gradually been exposed.

[0004] First, existing scheduling models typically require regional nodes to continuously report load-related operational data to a unified processing unit. This type of data often contains information reflecting user energy consumption behavior characteristics, equipment operating status, and sensitive system parameters. During cross-regional transmission and centralized processing, there is a risk of it being illegally obtained, misused, or leaked, making it difficult to balance data utilization efficiency with data security compliance requirements.

[0005] Secondly, the existing scheduling decision-making process lacks a complete, continuous, and reliable recording mechanism. The parameter updates of the load forecasting model, the basis for generating scheduling strategies, and the issuance of scheduling instructions are usually recorded in the form of internal logic or temporary records. When scheduling deviations, equipment malfunctions, or system accidents occur, it is difficult to effectively trace back the forecast basis, decision-making process, and execution status, which restricts the system's ability to define responsibility and continuously optimize its operation.

[0006] Furthermore, the performance of voltage regulator scheduling models is highly dependent on the continuous accumulation of historical forecast results and actual execution feedback. However, in existing methods, there is a lack of consistent and reliable means to ensure the data during collection, storage, or sharing. This makes the data susceptible to human intervention or abnormal data interference, resulting in an unreliable basis for model iteration and difficulty in accurately reflecting the true pattern of load changes. Consequently, this weakens the ability of rolling optimization scheduling to adapt to sudden load change scenarios.

[0007] Furthermore, in multi-regional collaborative operation scenarios, each voltage regulator node is both the source of load data and the main body for executing dispatch instructions. Existing technologies generally lack quantitative evaluation and incentive mechanisms for node participation, data contribution quality, and execution effectiveness, which can easily lead to insufficient node cooperation, incomplete data reporting, or delayed execution feedback, affecting the effectiveness and consistency of the overall dispatch strategy.

[0008] Finally, as system scale increases and operating environments become more complex, centralized scheduling structures often suffer from delayed response and limited adjustment capabilities when facing abnormal operating conditions, sudden loads, or local failures. Due to the high coupling between scheduling decisions and execution processes, it is difficult to make timely autonomous corrections once the state of a local node deviates, making it difficult to balance scheduling robustness and real-time performance.

[0009] In summary, existing rolling optimization scheduling methods for voltage regulators based on load forecasting still have significant shortcomings in terms of data security, process reliability, continuous model optimization, node collaboration motivation, and system robustness, making it difficult to meet the comprehensive requirements of new energy systems for intelligent, reliable, and adaptive scheduling capabilities. Therefore, there is an urgent need for a new rolling optimization scheduling method for voltage regulators that can reliably record the entire scheduling process, support continuous iterative optimization of the forecasting model, and effectively mobilize the collaboration motivation of each node, all while ensuring data security and privacy, in order to overcome the aforementioned technical bottlenecks. Summary of the Invention

[0010] To address the shortcomings of existing technologies, the present invention aims to provide a rolling optimization scheduling method for voltage regulators based on load forecasting, which simultaneously solves the technical defects of existing centralized scheduling modes, such as high risk of data leakage, opaque decision-making process, unreliable model optimization basis, insufficient node cooperation motivation, and difficulty in balancing real-time system response and robustness.

[0011] To achieve the above objectives, the present invention provides the following technical solution: a rolling optimization scheduling method for voltage regulators based on load forecasting, comprising the following steps: Step S1: Each regional voltage regulator node completes registration on the blockchain layer and obtains a unique node identifier; the smart contract deployed on the blockchain layer contains federated aggregation rules, scheduling compliance conditions, and node contribution rules; each node initializes a local load forecasting model and stores the initial parameters of the local load forecasting model on the blockchain layer. Step S2: Each node obtains local prediction results based on the data collected by the perception layer using the local load prediction model; the parameters of the local load prediction model and the local prediction results are encrypted using a homomorphic encryption algorithm to generate encrypted model data and upload it to the blockchain layer. Step S3: The smart contract verifies the received encrypted model data; performs federated aggregation on the verified data according to the federated aggregation rules to generate global load prediction model parameters and global prediction results; and generates scheduling instructions based on the global prediction results and the scheduling compliance conditions and sends them to the corresponding nodes. Step S4: Each node receives and executes the scheduling instruction. During the execution process, the situational awareness module monitors for anomalies and makes adaptive adjustments. After execution, execution feedback data containing actual load and status information is generated and uploaded to the blockchain layer for storage. Step S5: The smart contract iteratively optimizes the parameters of the global load prediction model based on the encrypted model data, scheduling instructions, and execution feedback data stored in the blockchain layer; calculates the contribution score of each node according to the node contribution rules and performs incentive allocation; and synchronizes the optimized global load prediction model parameters to each node to update the local load prediction model of each node.

[0012] Further, step S1 includes: Step S1.1, Node Registration and Information Storage: Each regional voltage regulator node submits a registration request to the blockchain layer. The registration request includes at least the node device model, load capacity limit, safe operation threshold, and historical scheduling record hash value. After verifying the registration request, the blockchain layer assigns a unique node identifier to each node and stores the basic node information, including the node device model, load capacity limit, safe operation threshold, and historical scheduling record hash value, in the distributed ledger. Step S1.2, Smart Contract Rule Deployment: In the smart contract deployed on the blockchain layer, the federated aggregation rule is configured to calculate the aggregation weight based on the historical prediction accuracy of each node; the scheduling compliance conditions are configured to include a load limit threshold, an energy consumption threshold, and a response time threshold; the node contribution rule is configured to be a weighted evaluation based on four dimensions: data quality, prediction accuracy, execution strength, and timeliness of anomaly reporting. Step S1.3, Local Model Initialization and Storage: Each node initializes the input feature range of the local load prediction model based on the load carrying capacity limit and safe operation threshold in the node basic information; the local load prediction model is constructed using a deep learning model architecture, and the initial parameters of the deep learning model architecture are used to generate initial parameter hash values, and the initial parameter hash values ​​are associated with the unique node identifier and stored in the blockchain layer.

[0013] Further, step S2 includes: Step S2.1, Multi-source data acquisition and fusion: The perception layer of each node acquires local load data, equipment operating status data and environmental data in real time; wherein, the equipment operating status data includes temperature, pressure and wear degree, and the environmental data includes humidity, air pressure and weather warning information; the local load data, equipment operating status data and environmental data are timestamped and fused to form fused feature data for model input; Step S2.2, Adaptive Rolling Forecast: Each node inputs the fused feature data into the local load forecasting model for forward calculation to obtain the local forecast result for the first time period in the future; wherein, the local load forecasting model is a long short-term memory network model based on an attention mechanism; the length of the first time period is dynamically adjusted according to historical forecast deviations or weather warning information in the environmental data; Step S2.3, Homomorphic Encryption and Data Encapsulation: The Paillier homomorphic encryption algorithm is used to encrypt the parameters of the local load forecasting model and the local forecasting results respectively, generating encrypted parameters and encrypted forecasting results; the encrypted parameters, the encrypted forecasting results, the unique node identifier of the corresponding node, the current timestamp, and the confidence assessment value of this forecast are encapsulated into a standardized data packet to generate the encrypted model data; Step S2.4, Triggered Trusted Evidence Storage: The encrypted model data is uploaded to the blockchain layer; after the smart contract in the blockchain layer detects the upload event, it automatically triggers the parameter receiving logic, parses the standardized data packet, verifies the validity of the unique node identifier, and associates and stores the encrypted parameters with the hash value of the encrypted prediction result, the timestamp, and the confidence assessment value in the distributed ledger, thus completing the evidence storage for this upload.

[0014] Further, in step S3, the smart contract verifies the received encrypted model data, specifically including: Step S3.1.1, Format and Permission Verification: The smart contract parses the encrypted model data, verifies whether its data format conforms to the preset encryption parameter format specification, and verifies whether the node identifier that uploaded the encrypted model data exists in the list of legitimate nodes registered in the blockchain layer. Step S3.1.2, Encryption strength and confidence verification: The smart contract verifies whether the homomorphic encryption algorithm type and key length used in the encrypted model data reach the preset security strength threshold, and determines whether the current prediction confidence assessment value contained in the encrypted model data is not lower than the preset confidence threshold. Step S3.1.3, Consensus Verification and Storage: The smart contract calls the preset consensus algorithm to verify the verification process and results among the consensus nodes in the blockchain layer; when the verification passes, the verification record containing the timestamp of this verification, the hash value of the verification result and the associated node identifier is written into the distributed ledger.

[0015] Further, in step S3, the validated data is federated according to the federated aggregation rules to generate global load forecasting model parameters and global forecasting results, specifically including: Step S3.2.1, Dynamic weight calculation: The smart contract calculates the dynamic aggregation weight of each node in the current aggregation round based on the historical prediction accuracy records of each node stored in the blockchain layer; wherein, the historical prediction accuracy is obtained by comparing the historical local prediction results with the actual load value in the corresponding historical execution feedback data; Step S3.2.2, Secure Aggregation Calculation: In the encrypted state, the smart contract calculates the weighted average of the encrypted parameters in the verified encrypted model data according to the dynamic aggregation weight of each node, and generates encrypted global load prediction model parameters. Step S3.2.3, Result Decryption and Publication: The smart contract uses the homomorphic encryption decryption key to decrypt the encrypted global load prediction model parameters to obtain the plaintext global load prediction model parameters; based on the global load prediction model parameters, forward inference is performed to generate the global prediction result, and the summary information of the global prediction result is stored in the blockchain layer.

[0016] Further, in step S3, based on the global prediction result and the scheduling compliance conditions, a scheduling instruction is generated and issued to the corresponding node, specifically including: Step S3.3.1, Strategy Space Generation and Constraint Matching: The smart contract uses the global prediction result as input and combines it with the preset scheduling optimization target to generate a preliminary scheduling strategy space; each strategy in the preliminary scheduling strategy space is matched and verified with the load limit threshold, energy consumption threshold and response time threshold included in the scheduling compliance conditions, and all feasible strategy sets that meet the constraints are selected. Step S3.3.2, Optimization strategy selection: The smart contract uses a preset optimization algorithm to calculate the optimal strategy from the set of feasible strategies; wherein, the optimization algorithm takes comprehensive economic efficiency, security and stability indicators as the objective function; Step S3.3.3, Instruction Standardization and Trigger Issuance: The smart contract transforms the optimal strategy into standardized scheduling instructions, which at least include the target voltage regulator node identifier, the target opening adjustment value, and the expected execution time window; the smart contract issues the scheduling instructions to the corresponding target voltage regulator node by calling the event publishing function of the blockchain layer.

[0017] Further, step S4 includes: Step S4.1, Edge computing execution and status monitoring: Each node receives and parses the scheduling instructions through the locally deployed edge computing unit, and completes the adjustment of the voltage regulator opening within the expected execution time window; at the same time, it collects the actual load data stream and equipment status data stream in real time after the execution starts. Step S4.2, Situational Awareness Anomaly Identification and Classification: Based on the actual load data stream, calculate the real-time deviation between it and the global prediction result that triggered this scheduling instruction; when the absolute value of the real-time deviation continuously exceeds the preset deviation threshold, trigger the anomaly monitoring process; the situational awareness module classifies the anomaly source according to the associated equipment status data stream and environmental data, identifying it as one of equipment failure, malicious attack or real load change; Step S4.3, Adaptive Strategy Execution for Abnormal Scenarios: If a device failure is identified, the startup process of the backup voltage regulator associated with the node is automatically triggered, and the failure event is reported to the blockchain layer; if a malicious attack is identified, the attack feature data is extracted, encrypted and uploaded to the blockchain layer for evidence storage, and a preset defensive scheduling strategy is used to overwrite the current scheduling instruction; if a real load change is identified, the rolling time window of the next round of prediction is dynamically shortened to a preset shortening value, and a non-periodic load prediction and parameter upload process is immediately triggered. Step S4.4, Execution Feedback Encapsulation and Trusted Evidence Storage: After the scheduling instruction execution cycle ends, each node generates an execution feedback data packet. The execution feedback data packet includes at least the average actual load value within the cycle, the final equipment operating status, the prediction deviation statistics, and the anomaly handling record. The data hash value of the execution feedback data packet is calculated, and the data hash value, the associated scheduling instruction identifier, and the node identifier are uploaded to the blockchain layer. After receiving the uploaded data, the smart contract automatically triggers the feedback evidence storage logic, writes the data hash value into the distributed ledger, and associates it with the corresponding scheduling instruction record.

[0018] Further, in step S5, the parameters of the global load prediction model are iteratively optimized, specifically including: Step S5.1.1, Trusted Data Backtracking and Extraction: During a preset low-load period, the smart contract extracts the full amount of trusted data corresponding to the current iteration cycle from the distributed ledger of the blockchain layer; the full amount of trusted data includes the encrypted model data uploaded by each node and its storage hash, all scheduling instructions issued, and all execution feedback data fed back by each node; Step S5.1.2, Parameter Adaptive Adjustment: Based on the full set of reliable data, analyze the overall prediction performance trend of the global load prediction model in the most recent iteration cycle; according to the performance trend, adjust the parameters of the global load prediction model through a preset optimization algorithm, wherein the global load prediction model parameters include at least the learning rate, the number of network layers, and the attention mechanism weights; Step S5.1.3, Dynamic update of aggregation weight: Based on the historical execution feedback data in the full trusted data, recalculate the historical prediction accuracy of each node; based on the recalculated historical prediction accuracy and the node instruction execution completion rate, update the dynamic aggregation weight of each node in the next round of federated aggregation according to the preset rules.

[0019] Further, in step S5, calculating the contribution score of each node according to the node contribution rule specifically includes: Step S5.2.1, Multi-dimensional indicator quantification: The smart contract obtains raw indicator data for evaluating contribution from the evidence storage data of the blockchain layer; the raw indicator data includes: the integrity and timeliness indicators of data uploaded by each node, the deviation rate between the historical local prediction results of each node and the corresponding actual load value, the execution completion degree of each node to the scheduling instructions, and the timeliness and accuracy records of abnormal events reported by each node. Step S5.2.2, Weighted Comprehensive Score Calculation: The smart contract quantifies and scores the indicators of data quality, prediction accuracy, execution strength, and anomaly reporting according to the weight allocation preset in the node contribution rules; the quantified scores of each dimension are weighted and summed to calculate the comprehensive contribution score of each node. Step S5.2.3, Standardization and Ranking of Scores: Standardize the comprehensive contribution score and rank all nodes in descending order according to the standardized score; store the contribution list containing node identifiers, scores and rankings in the distributed ledger of the blockchain layer.

[0020] Further, in step S5, performing incentive allocation and synchronizing the optimized global load prediction model parameters to each node specifically includes: Step S5.3.1, Execution of tiered incentive strategy: The smart contract executes differentiated incentives based on the contribution ranking results; for nodes ranked in the first preset percentage range, priority allocation of scheduling resources and priority adaptation of model iteration parameters are granted; for nodes ranked in the second preset percentage range, priority of operation and maintenance services is granted. Step S5.3.2, On-chain public disclosure of incentive results: The smart contract generates an incentive transaction record and writes it into the blockchain layer, including the incentive granting results, including the incentive type, granting node identifier and effective conditions, to complete the public disclosure; Step S5.3.3, Security Parameter Synchronization and Local Fine-tuning: The smart contract synchronizes the iteratively optimized global load prediction model parameters to each node through a secure channel; after receiving the parameters, each node uses recently collected fusion feature data to fine-tune the local load prediction model locally, thus completing the model update.

[0021] The beneficial effects of this invention are: Compared with the prior art, the present invention has at least the following significant advantages: 1. Achieving unified privacy protection and compliance in load forecasting and scheduling scenarios: This invention constructs local load forecasting models at each voltage regulator node and participates in the global model construction in a parameter-level manner. This ensures that the original load-related data is always kept at the local node and only participates in cross-node collaborative processing in an encrypted state. From a technical mechanism perspective, this avoids the risks of centralized aggregation and cross-domain transfer of original load data, effectively reduces the probability of sensitive information leakage, and can meet the compliance requirements of data security and privacy protection regulations on minimized data use and controllable sharing without compromising forecasting accuracy.

[0022] 2. Construct a reliable recording and traceability mechanism for the entire scheduling process: By continuously recording key aspects such as model parameter storage, collaborative aggregation results, scheduling instruction generation and execution feedback, a complete data link is formed between load forecasting and scheduling decision-making processes, and the relevant information possesses tamper-proof and verifiable characteristics. When scheduling deviations, equipment anomalies, or system failures occur, the model state evolution, decision-making basis, and execution process can be quickly reconstructed based on the records, thereby improving the operational transparency and accountability of the voltage regulator scheduling system.

[0023] 3. Improve the reliability and effectiveness of load forecasting model iterative optimization: Since model parameters, forecast results, and execution feedback are all stored and invoked based on a trusted mechanism, the possibility of training data being tampered with or distorted is avoided. This ensures that the iterative updates of the global model are based on data that truly reflects the characteristics of load changes, thereby enhancing the model's ability to characterize dynamic load fluctuations. Compared to scheduling methods that rely on unreliable historical data, this invention can maintain a stable improvement in forecasting performance during continuous rolling scheduling, making the scheduling strategy more closely aligned with actual operating conditions.

[0024] 4. Enhance participation willingness and execution consistency under multi-node collaborative scheduling: By quantitatively evaluating the performance of each node in model training, prediction contribution and scheduling execution, and combining the evaluation results with the incentive allocation mechanism, nodes form a positive feedback relationship in the process of participating in collaborative modeling and executing scheduling instructions. This effectively reduces phenomena such as data reporting delays, inadequate execution or concealment of abnormal information, and improves the collaborative consistency and scheduling reliability among multi-region voltage regulator nodes at the system level.

[0025] 5. Balancing real-time scheduling with system robustness: This invention decentralizes load forecasting and scheduling execution capabilities to the node side, enabling voltage regulators to respond and execute quickly upon receiving scheduling commands. Simultaneously, during execution, situational awareness is used to continuously monitor and adaptively adjust for abnormal operating conditions. When sudden load changes, equipment malfunctions, or local disturbances occur, rolling corrections can be achieved without relying on centralized recalculation. This improves scheduling response speed while effectively reducing the impact of abnormal operating conditions on the overall system stability. Attached Figure Description

[0026] Figure 1 This is a flowchart of the steps of the voltage regulator rolling optimization scheduling method based on load forecasting in this invention; Figure 2 This is a flowchart of step S1 in this invention; Figure 3 This is a flowchart of step S2 in this invention; Figure 4 This is a flowchart of step S3.1 in this invention; Figure 5 This is a flowchart of step S3.2 in this invention; Figure 6 This is a flowchart of step S3.3 in this invention; Figure 7 This is a flowchart of step S4 in this invention; Figure 8 This is a flowchart of step S5.1 in this invention; Figure 9 This is a flowchart of step S5.2 in this invention; Figure 10 This is a flowchart of step S5.3 in this invention. Detailed Implementation

[0027] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Identical components are denoted by the same reference numerals. It should be noted that the terms "front," "rear," "left," "right," "upper," and "lower" used in the following description refer to directions in the accompanying drawings, and the terms "bottom surface," "top surface," "inner," and "outer" refer to directions toward or away from the geometric center of a specific component, respectively.

[0028] Example 1, refer to Figure 1 This is the first embodiment of the present invention, which provides a rolling optimization scheduling method for pressure regulators based on load forecasting. The following describes the rolling optimization scheduling method for pressure regulators based on load forecasting proposed in this invention in detail with reference to a specific application scenario - urban gas pressure regulator scheduling system.

[0029] (a) System deployment architecture and operating environment; In this embodiment, the voltage regulator rolling optimization scheduling system is deployed according to a layered architecture of perception layer—federated learning layer—blockchain layer—rolling optimization and execution layer, with each layer working together to achieve the method described in claim 1.

[0030] 1. Deployment of the perception layer: The following sensing and data acquisition devices are installed at gas pressure regulator stations in various urban areas: Pressure acquisition device: MEMS pressure sensor, used to acquire the inlet and outlet pressure of the pressure regulator in real time; Flow acquisition device: Gas flow sensor, used to collect gas load flow per unit time; Temperature acquisition device: Industrial-grade temperature sensor, used to acquire the temperature of the voltage regulator and the ambient temperature; Environmental sensing devices: humidity sensor and weather early warning module, used to collect environmental humidity and extreme weather early warning information.

[0031] All the aforementioned sensors are connected to the local computing unit of their respective sites via NB-IoT narrowband Internet of Things communication modules, enabling minute-level data acquisition and uploading. In this embodiment, the sampling period is set to 1 minute.

[0032] 2. Federated Learning Layer Deployment: Each gas pressure regulator site is equipped with a local edge computing unit, which uses an ARM architecture processor and runs an embedded Linux system to execute local load forecasting models.

[0033] In this embodiment, the local load forecasting model adopts a time-series forecasting model that combines LSTM neural network and attention mechanism to characterize the time-series dependence characteristics of gas load and the weight distribution of key time periods.

[0034] Deploy federated aggregation nodes in the city gas dispatch center to perform federated aggregation of model parameters uploaded by each station without obtaining the original load data of each station, and generate global load prediction model parameters.

[0035] 3. Blockchain layer deployment: The blockchain layer adopts a consortium blockchain architecture, with on-chain nodes including: gas pressure regulator sites in various regions; city gas dispatch centers; operation and maintenance unit nodes; and industry regulatory department nodes.

[0036] The consortium blockchain adopts the PBFT consensus mechanism, with a block generation interval set at 10 seconds to balance system real-time performance and consensus reliability.

[0037] The smart contract is developed using the Solidity language and deployed in the Ethereum consortium blockchain environment to automatically execute federated aggregation rules, scheduling compliance conditions, and node contribution rules.

[0038] 4. Rolling optimization and execution layer deployment: Digital twin modules are integrated into the edge computing units of each voltage regulator site to construct a virtual simulation model consistent with the physical voltage regulator parameters, which is used to simulate the changes in the operating state of the voltage regulator before and after the execution of instructions.

[0039] The dispatch center deploys a global monitoring platform to display the real-time operating status, prediction results, dispatch instructions, and execution feedback information of each site.

[0040] (II) Specific execution process and working principle; 1. Initialization phase, corresponding to step S1: Each gas pressure regulator site first registers on the consortium blockchain and obtains a unique node identifier (NodeID). During the registration process, each site uploads and stores the following basic information to the blockchain layer: Voltage regulator model (e.g., RTZ-31 / 0.41). Maximum load capacity: 500m 3 / h; Safe operating temperature range: -20℃~60℃.

[0041] At the same time, the smart contract completes its initial configuration, including: Initial weights for federated aggregation: Initial aggregation weights for each node; Dispatch compliance threshold: Load limit ≤ 500m 3 / h; Scheduling instruction execution delay ≤500ms; Node contribution rule weight allocation: Data quality weight: 30%; Prediction accuracy weight: 40%; Command execution completion weight: 20%; Anomaly reporting timeliness weight: 10%.

[0042] Each site completes the initialization of its local load forecasting model and stores the initial parameter summary information of the model in the blockchain layer for subsequent model evolution tracking.

[0043] 2. Local load forecasting and encrypted parameter upload, corresponding to step S2: Each station's sensing layer device collects gas flow, equipment temperature, and environmental data every minute, and combines this data with the station's historical load data from the past three months. The data is then input into the local LSTM load prediction model to predict the gas load change trend for the next 10 minutes.

[0044] To prevent model parameters from being leaked or tampered with during transmission, nodes use the Paillier homomorphic encryption algorithm to encrypt the parameter set, generate encrypted model data, and then upload it to the blockchain layer, thereby supporting subsequent federated aggregation operations without exposing plaintext parameters.

[0045] 3. Parameter aggregation and scheduling instruction generation, corresponding to step S3: The smart contract performs integrity and compliance checks on the received encrypted model data at the blockchain layer, including: verification of the legality of the encryption algorithm; verification of the consistency of the parameter format; and verification of the upload time window.

[0046] After successful verification, the federated aggregation node aggregates the model parameters of each node according to the federated aggregation rules to generate global load forecasting model parameters. This aggregation method enables the global model to comprehensively reflect the load change characteristics of multiple regions without touching the original load data.

[0047] Based on the global load forecast, the smart contract automatically generates scheduling instructions for each site, such as adjusting the voltage regulator opening from 60% to 55%. The generated scheduling instructions must meet the load limit and execution delay threshold requirements, and are sent to the corresponding sites after verification and compliance.

[0048] 4. Scheduling execution, situational awareness and feedback, corresponding to step S4: After receiving the scheduling command, the edge computing unit of each site first simulates the execution effect through the digital twin module. After confirming that there is no security risk, it controls the physical voltage regulator to perform the corresponding opening adjustment.

[0049] During execution, the system continuously monitors the deviation between the actual load value and the predicted load value. When the deviation is greater than 15%, it is determined to be an abnormal operating condition and automatically triggers the abnormal identification and adaptive adjustment mechanism, such as starting the backup voltage regulator or adjusting the scheduling parameters.

[0050] The exception type, processing procedure, and execution result form execution feedback data, which is then encrypted and uploaded to the blockchain layer for evidence storage.

[0051] 5. Model iterative optimization and node activation, corresponding to step S5: The system triggers the model iteration process at 1 a.m. every day. The smart contract extracts encrypted model data, scheduling instructions and execution feedback data from the blockchain layer and calculates the contribution score of each node.

[0052] The contribution score is calculated based on the aforementioned weighting rules and is used to dynamically adjust the node weights in the next round of federated aggregation. Nodes ranking in the top 30% of contribution receive an 8% increase in aggregation weight, thereby guiding high-quality nodes to play a greater role in model evolution.

[0053] Meanwhile, the global model is optimized based on reliable data, for example, by adjusting the learning rate of the LSTM model from 0.001 to 0.0008 to improve the model's convergence stability.

[0054] 6. Traceability and regulatory support: As a node in the consortium blockchain, regulatory authorities can query the model parameter evolution records, dispatch instruction generation logic, and execution feedback information of each pressure regulator site at any time. In the event of a gas supply interruption or safety incident, the responsible node and decision-making process can be quickly located through on-chain data, enabling reliable traceability throughout the entire process.

[0055] (III) Verification of technical effectiveness; In a pilot application at 20 gas pressure regulator stations in a certain city, this embodiment achieved the following technical effects: 1. The raw load data is always kept on the local node, without centralized aggregation, which significantly reduces the risk of data leakage; 2. The average deviation of load forecasting decreased from 22% to 11%, significantly improving forecasting accuracy; 3. The average execution delay of the scheduling instructions is 320ms, which meets the real-time requirement of ≤500ms; 4. Under abnormal load scenarios, the scheduling deviation is controlled below 10%, and the system robustness is significantly enhanced; 5. The timely reporting rate of node data has been improved to 98%, and the average response time for abnormal information has been shortened to 45 seconds.

[0056] Example 2 is the second embodiment of the present invention. Unlike the previous embodiment, this embodiment focuses on further defining and refining the node registration, local load prediction model construction, multi-source data fusion, adaptive rolling prediction, and homomorphic encrypted upload mechanism based on the system architecture described in Example 1.

[0057] I. For the specific implementation method and working principle of step S1, please refer to... Figure 2 : (I) Step S1.1: Node registration and information storage; During the system initialization phase, each regional voltage regulator node submits a node registration request to the blockchain layer. The registration request must include at least the following basic information fields: Voltage regulator equipment model , used to characterize the hardware performance level of a node; Load Capacity Limit The unit is m 3 / h; safe operation threshold set This includes: the upper limit of safe pressure and the safe temperature range; Historical scheduling record hash value This is used to reflect the integrity of a node's past scheduling behavior.

[0058] After completing the legitimacy verification, the blockchain layer assigns a unique node identifier to each node. And the above-mentioned basic node information and unique node identifier are combined. The associated data is stored in a distributed ledger, thus providing a foundational data source for subsequent trusted model initialization and accountability.

[0059] Technical effect: By completing on-chain notarization of the basic capabilities and security boundaries of nodes before the model runs, the system avoids subsequent nodes from affecting the model aggregation results by tampering with device parameters or historical behavior information, thereby enhancing the credibility of the initial state of the system.

[0060] (ii) Step S1.2: Deployment of smart contract rules; Configure the following rules in the smart contract deployed at the blockchain layer: 1. Smart Contract Rule Deployment: In smart contracts deployed at the blockchain layer, federated aggregation rules are configured to calculate aggregation weights based on the historical prediction accuracy of each node; 2. Dispatch compliance conditions: The dispatch command must simultaneously meet the following threshold constraints: predicted load Energy consumption per unit time Command response time ; 3. Node contribution rules: Node contribution score Defined as: ; in, Score the data quality. To score the prediction accuracy, To perform completion scoring, A score is given for the timeliness of abnormal reporting.

[0061] Technical effect: The above rules constrain node behavior through multi-dimensional weighted functions, enabling model aggregation, scheduling generation and incentive allocation to form a closed-loop logic, thereby improving overall collaborative stability.

[0062] (III) Step S1.3: Initialization and verification of the local load forecasting model; Each node is based on its load capacity limit. With safe operating threshold The input features of the model are normalized to ensure that the model prediction results always fall within a safe and executable range.

[0063] The local load prediction model employs a Long Short-Term Memory (LSTM+Attention) network structure based on an attention mechanism, and its core parameter set is defined as follows: ; in, These are the weight matrices for the forget gate, input gate, output gate, and candidate states, respectively. This is the weight matrix for the attention mechanism; This is the bias vector.

[0064] The node generates a hash value for the initial parameter set. And combine the hash value with the node identifier. The evidence is stored on the blockchain layer.

[0065] Technical effect: By fixing the model structure and initial parameter state on the chain, the unauthorized replacement of the model architecture by nodes is prevented, ensuring the consistency and traceability of the starting point of federated training.

[0066] II. For the specific implementation method and working principle of step S2, please refer to... Figure 3 : (I) Step S2.1: Multi-source data acquisition and fusion; The perception layer of each node collects the following three types of data: Local load data ; Equipment operating status data: Temperature ,pressure Wear ; Environmental data: Humidity air pressure Weather warning level .

[0067] After aligning with timestamps, construct the fused feature vector: ; in, To fuse feature vectors.

[0068] (ii) Step S2.2: Adaptive rolling forecast (core of local load forecasting model); 1. LSTM timing modeling function: The state update of an LSTM cell is defined as follows: ; in, Let be the hidden state at time t. It is a composite mapping consisting of gated nonlinear functions.

[0069] 2. Attention-weighted prediction function: Introducing attention weights : ; The final prediction result is: ; in, This represents intermediate features; It is a nonlinear regression function; This represents the length of the rolling forecast period.

[0070] 3. Adaptive rules for scrolling windows: Prediction window length Dynamic adjustments will be made according to the following rules: ; Technical effect: By using a composite function structure of "LSTM + attention + adaptive window", the model can not only capture long-term load trends, but also quickly shorten the prediction cycle under abnormal conditions, thereby improving the scheduling response sensitivity.

[0071] (III) Step S2.3: Homomorphic encryption and data encapsulation; Node-to-model gradient parameters and prediction results Encryption is performed using the Paillier homomorphic encryption algorithm, generating: encryption gradient parameters. and encrypted prediction results .

[0072] Simultaneously calculate the prediction confidence level: ; Finally, an encrypted model data packet is generated: .

[0073] Technical benefits: This data encapsulation method protects the privacy of model parameters and prediction results while providing a quantitative basis for subsequent aggregation weight calculation and scheduling credibility assessment.

[0074] III. Overall technical effects of Example 2: 1. The structure, parameters, and reasoning logic of the local load forecasting model are clearly defined to ensure model reproducibility; 2. Joint modeling of multiple complex functions significantly improves the adaptability of load forecasting to abnormal scenarios; 3. Homomorphic encryption and blockchain notarization work together to achieve data flow that is "computable but not viewable"; 4. Provides a highly reliable and accurate predictive input basis for the rolling optimization scheduling in Example 1.

[0075] Example 3, the third embodiment of the present invention, further elaborates on the integrated execution mechanism of smart contract-driven federated aggregation, verification, and scheduling decisions in step S3, building upon the node registration, local load prediction, and homomorphic encrypted upload described in Example 2. The core of this embodiment lies in solidifying the model's trusted aggregation and business-level scheduling decisions into continuous automatic execution logic within the same smart contract, constructing an inseparable trusted chain-like closed loop of "aggregation—verification—decision—distribution".

[0076] I. Explanation of the overall working principle of step S3: In this embodiment, all encrypted model data uploaded by nodes is not processed by any centralized server, but is directly handled by a smart contract deployed on the blockchain layer. This smart contract, in a continuous execution process, completes the following sequentially: Compliance verification of encrypted model data; Federal security aggregation based on historical prediction accuracy; Scheduling strategy generation and instruction issuance based on global prediction results.

[0077] The above three stages are completed by the same smart contract instance in the same execution logic, and their input data, rule parameters and output results are all verifiable and traceable at the blockchain layer, thus forming an automatic decision-making chain that is tamper-proof, non-repudiable and requires no human intervention.

[0078] II. Verification and Consensus Notation of Encrypted Model Data (Step S3.1, refer to...) Figure 4 ): (a) Step S3.1.1: Format and permission verification; When the smart contract in the blockchain layer receives encrypted model data uploaded from each voltage regulator node... First, it undergoes structured parsing. The encrypted model data includes at least: Encryption model parameters ; Encrypted prediction results Node unique identifier Upload timestamp ; Predicted confidence level assessment value .

[0079] Smart contracts verify the following two types of conditions: 1. Data format consistency condition: judgment Whether the preset field structure and coding specifications are met, so as to avoid non-standard data from participating in subsequent aggregation.

[0080] 2. Node permission validity conditions: Determine the node identifier. Does it exist in the list of legitimate node registrations in the blockchain layer? The registration list comes from the node registration and information storage completed in step S1.

[0081] Only when both of the above conditions are met will the encrypted model data enter the next verification stage.

[0082] Technical effect: By performing pre-filtering of format and permissions on the blockchain, illegal nodes or abnormal data are prevented from interfering with the federated aggregation process, thereby improving the credibility of the model's aggregated input data.

[0083] (ii) Step S3.1.2: Encryption strength and confidence verification; After confirming the format and node legitimacy, the smart contract further verifies the security and reliability of the encrypted model data, specifically including: 1. Encryption strength verification: Verify that the homomorphic encryption algorithm used is the default algorithm (Paillier), and verify that the key length meets the requirements: ; in, The actual key length used (unit: bit); To preset the security strength threshold, 1024 bits are used in this embodiment.

[0084] 2. Prediction confidence verification: Verify the prediction confidence assessment value Does it meet the following requirements: ; in, The confidence threshold is set to 0.7 in this embodiment.

[0085] Technical effect: By simultaneously constraining encryption strength and prediction reliability, low-security or low-reliability data is prevented from entering the aggregation process, thereby improving the security and stability of the global model.

[0086] (III) Step S3.1.3: Consensus verification and verification result storage Once the encrypted model data passes the above verification, the smart contract calls the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm preset in the blockchain layer to verify the consistency of the verification process and results among multiple consensus nodes.

[0087] The basic working principle of the PBFT consensus algorithm is as follows: Consensus nodes confirm the consistency of verification results through a three-stage message exchange: pre-preparation, preparation, and commit. Consensus is considered successful when no fewer than 2f+1 consensus nodes reach an agreement on the verification result (where f is the number of Byzantine fault nodes that the system can tolerate).

[0088] Once consensus is reached, the smart contract will write the following information into the distributed ledger: the timestamp of this verification; the hash value of the verification result; and the identifier of the associated node.

[0089] Technical effect: This consensus mechanism ensures that the verification conclusion is not given unilaterally by a single node or a single contract instance, but is verified and confirmed by multiple independent consensus nodes, effectively preventing malicious nodes from forging "verification passed" results, thereby ensuring the credibility of inputs for subsequent aggregation and scheduling decisions.

[0090] III. Dynamic Weight Calculation and Secure Federated Aggregation (Step S3.2, refer to...) Figure 5 ): (a) Step S3.2.1: Calculation of dynamic aggregation weights; Smart contracts calculate the dynamic weight of each node in the current aggregation round based on historical data stored in the blockchain layer.

[0091] The historical prediction error of node i is defined as: ; in, The number of samples within the historical evaluation window. Let be the predicted load for node i in the m-th prediction. This corresponds to the actual load in the execution feedback.

[0092] Based on historical prediction errors, calculate the dynamic aggregation weight of node i: ; in, This represents the total number of nodes participating in the aggregation. It is an exponential function used to amplify differences in prediction accuracy.

[0093] Technical effect: This nonlinear weighting function enables nodes with high prediction accuracy to contribute more to the global model, effectively suppressing the negative impact of low-quality nodes on the aggregation results.

[0094] (ii) Step S3.2.2: Secure aggregation calculation; Under homomorphic encryption, the smart contract performs a weighted aggregation operation on the encrypted model parameters uploaded by each node to generate encrypted global load prediction model parameters: ; in, Let i be the encryption model parameters for node i. These are the parameters for the global load prediction model under encrypted conditions.

[0095] Because homomorphic encryption supports addition and scalar multiplication, the above calculation process is always completed in the ciphertext space, and no node can obtain the plaintext model parameters of other nodes.

[0096] Technical effect: It enables secure federated aggregation that is "computable but not visible", balancing model performance improvement and data privacy protection.

[0097] (III) Step S3.2.3: Result decryption and global prediction generation; Aggregator nodes, under the premise of satisfying access control, utilize homomorphic encryption / decryption key pairs. Decryption is performed to obtain the plaintext global load prediction model parameters. .

[0098] Based on the parameters of the global load prediction model, forward inference is performed to obtain the global prediction result, and the summary information (hash value and timestamp) of the prediction result is stored in the blockchain layer.

[0099] The global prediction results are configured as follows: ; in, This is a global feature summary formed by aggregating the prediction results of each node. The load forecasting inference function is consistent with that in Example 2. This is the global prediction result.

[0100] Technical benefits: Ensures that the global prediction results are reliable and the process is traceable, providing reliable input for scheduling decisions.

[0101] IV. Generation and distribution of scheduling strategies based on compliance constraints (Step S3.3, refer to...) Figure 6 ): (a) Step S3.3.1: Policy space generation and constraint matching; Smart contracts use global prediction results Using the input as the basis and combining it with the preset scheduling optimization objective, a set of candidate scheduling strategies is generated. For each scheduling policy in the candidate scheduling policy set Verify whether it simultaneously satisfies the following constraints: Forecasted load Energy consumption per unit time Command response time .

[0102] Strategies that meet the above conditions constitute a set of feasible strategies. .

[0103] (ii) Step S3.3.2: Optimization strategy selection; In the set of feasible strategies In this context, smart contracts select the optimal strategy based on a comprehensive objective function. The objective function is configured as follows: ; ; in, As an economic indicator, To ensure operational safety indicators, α, β, and γ are system stability indicators, and are weighting coefficients.

[0104] By minimizing The optimal scheduling strategy is obtained.

[0105] Technical effect: This multi-objective optimization function avoids scheduling bias caused by a single objective while ensuring safety and stability, and improves the overall performance of rolling scheduling.

[0106] (III) Step S3.3.3: Standardization and issuance of scheduling instructions; Smart contracts translate the optimal strategy into standardized scheduling instructions, which include at least: the target voltage regulator node identifier; the target opening adjustment value; and the expected execution time window.

[0107] Smart contracts use the event publishing mechanism of the blockchain layer to send scheduling instructions to the corresponding voltage regulator nodes.

[0108] Technical benefits: It ensures that the scheduling instruction generation process is automated and transparent, and ensures that instructions are delivered in a trusted environment.

[0109] V. Overall technical effects of Example 3: 1. A "hard connection" between federated learning outputs and real-time scheduling decisions; 2. End-to-end automated execution, from encrypted parameters to scheduling instructions; 3. Eliminate the single point of failure and tampering risk of centralized decision-making servers; 4. Achieve reliable, efficient, and traceable rolling optimization scheduling of voltage regulators without data leaving the domain.

[0110] This design is not a simple parallel application of federated learning and blockchain, but rather an automated decision-making agent mechanism that uses smart contracts to solidify rules, make processes transparent, and verify results, significantly improving the system's security, reliability, and engineering feasibility.

[0111] Example 4 is the fourth embodiment of the present invention. Based on the "smart contract-driven aggregation-verification-decision integrated automatic link" of Example 3, this embodiment further expands steps S4 and S5 to construct a global model continuous evolution mechanism with edge computing as the execution subject, blockchain as the trusted feedback carrier, and optimization algorithm as the driver, so as to realize the long-term stability and adaptive optimization of the voltage regulator rolling optimization scheduling system in complex operating environments.

[0112] Step S4: The working principle of local scheduling execution and reliable data feedback is referred to... Figure 7 : (a) Step S4.1: Edge computing execution and status monitoring; After receiving the scheduling instruction issued by the smart contract, each voltage regulator node parses the instruction through an edge computing unit deployed locally on the node. The scheduling instruction includes at least the target voltage regulator node identifier, the target opening adjustment value, and the expected execution time window.

[0113] The edge computing unit directly drives the voltage regulator to adjust its opening within the expected execution time window, achieving millisecond-level local execution response and avoiding the cumulative latency caused by network transmission in a centralized scheduling architecture. Simultaneously, from the start of scheduling execution, the edge computing unit continuously collects the following data streams: actual load data stream. ; and equipment status data streams, including temperature T(t), pressure P(t), and wear W(t).

[0114] All of the above data are accompanied by a unified timestamp for subsequent situational awareness analysis and execution feedback encapsulation.

[0115] Technical benefits: By executing scheduling instructions directly at the edge, the length of the control loop is significantly shortened, the real-time performance of scheduling is improved, and local computing power is provided to support rapid response to anomalies.

[0116] (ii) Step S4.2: Situational awareness anomaly identification and classification; The edge computing unit uses real-time collected actual load data streams and global prediction results that triggered the current scheduling command. Calculate real-time deviation: ; in, Let be the prediction deviation value at time t.

[0117] when The continuous time length is not less than The deviation continuously exceeds the preset threshold within the monitoring window. When this occurs, the anomaly monitoring process is triggered.

[0118] In this embodiment, the deviation threshold is specifically set to ±20% of the predicted value, that is: ; The situational awareness module combines equipment status data streams and environmental data to classify the sources of anomalies, and the identification results are limited to one of the following three categories: equipment failure; malicious attack; and sudden change in actual load.

[0119] Technical effect: This joint discrimination mechanism based on deviation threshold and multi-source situational data can effectively avoid misjudgment by a single indicator and improve the accuracy and timeliness of anomaly identification.

[0120] (III) Step S4.3: Execution of adaptive strategies for abnormal scenarios; For different anomaly types, edge computing units execute differentiated adaptive strategies: Equipment failure scenario: The system automatically triggers the startup process of the backup voltage regulator associated with the node and encrypts and reports the failure event, which includes the failure type, occurrence time and equipment identifier, to the blockchain layer for evidence storage.

[0121] Malicious attack scenario: Extract attack feature data and encrypt it before uploading it to the blockchain layer; at the same time, adopt a preset defensive scheduling strategy to override the current scheduling instructions to ensure system operation security.

[0122] Real-world load surge scenario: Dynamically shorten the rolling time window of the next load forecast to a preset shortening value, which is specifically set to 5 minutes in this embodiment; and immediately trigger a non-periodic load forecast and parameter upload process.

[0123] Technical effect: By using an exception type-driven strategy for traffic diversion, the system can maintain stable operation when faced with sudden operating conditions, and provides real and clearly labeled data samples for subsequent model optimization.

[0124] (iv) Step S4.4: Perform feedback encapsulation and trusted evidence storage; After the scheduling instruction execution cycle ends, each node generates an execution feedback data packet. The execution feedback data packet includes at least: the average actual load value during the cycle; the final equipment operating status; the prediction deviation statistics; and the anomaly handling record.

[0125] Each node calculates a hash value for the execution feedback data packet and uploads this hash value, along with the associated scheduling instruction identifier and node identifier, to the blockchain layer. Upon receiving the uploaded data, the smart contract automatically triggers the feedback notarization logic, writing the hash value into the distributed ledger and associating it with the corresponding scheduling instruction record.

[0126] Technical effect: It forms a reliable closed loop with a one-to-one correspondence between "scheduling instructions - local execution - execution feedback" and cannot be tampered with, providing a highly reliable training basis for subsequent model optimization.

[0127] II. Step S5: Model Iterative Optimization and Incentive Coordination Driven by Trusted Data Closed-Loop (I) Step S5.1: Adaptive optimization of global load forecasting model parameters, referring to Figure 8 ; 1. Trusted data backtracking and extraction: The smart contract extracts all trusted data from the blockchain layer during a preset low-load period (e.g., 00:00–02:00 daily). This full set of trusted data includes at least: encrypted model parameters and their notarized hashes uploaded by each node in each iteration; records of the federated aggregation process; all scheduling instructions; and execution feedback data and anomaly handling records from each node.

[0128] 2. Definition of global prediction performance metrics: Within the current iteration period, the average prediction error of the global load forecasting model is defined as follows: ; in, The average prediction error for the k-th iteration period is... This represents the number of time steps included in the statistics within that period.

[0129] The predicted performance trend is defined as the change in error between adjacent iteration cycles: ; in, This represents the change in error between adjacent iteration cycles.

[0130] 3. Parameter adaptive adjustment algorithm and formula: This embodiment employs an adaptive optimization algorithm based on performance trend feedback to jointly adjust the parameters of the global load prediction model. Hyperparameters include at least: learning rate. Network layers ; and attention mechanism weight coefficients .

[0131] (1) Learning rate adjustment formula; ; in, and These are the learning rates for the current and next iteration cycles, respectively. This is the learning rate adjustment coefficient, used to control the adjustment range.

[0132] (2) Rules for adjusting the number of network layers; The network layer count adjustment is triggered when the following conditions are met: ; in, Adjust the threshold for the number of layers.

[0133] When the conditions are met, the network layer number is updated as follows: ; Otherwise, it remains unchanged.

[0134] (3) The formula for adjusting the weights of the attention mechanism; ; in, , These are the attention weights for the current and next cycles, respectively. This is the attention modulation coefficient.

[0135] Technical effect: By directly mapping the actual prediction bias in the execution feedback to the joint adjustment of the learning rate, network depth and attention weight, the global model structure and training intensity can continuously fit the characteristics of real load changes, avoiding long-term model drift or overfitting.

[0136] (ii) Step S5.2: Node contribution assessment, referring to Figure 9 ; The smart contract uses blockchain-stored data to quantitatively score nodes across four dimensions: data quality, prediction accuracy, execution strength, and anomaly reporting. These scores are then weighted and summed according to preset weights to obtain a comprehensive contribution score. After standardization, this comprehensive score generates a ranking list of node contributions, which is then stored on the blockchain layer.

[0137] (III) Step S5.3: Incentive allocation and model synchronization, refer to Figure 10 ; The smart contract implements a tiered incentive strategy based on contribution rankings, granting the top 30% of nodes priority in allocating scheduling resources, prioritizing operational services, and adapting model iteration parameters. After the incentive results are published on-chain, the iteratively optimized global load prediction model parameters are synchronized to all nodes via a secure channel. Each node then fine-tunes its local model using recent fused feature data, thus updating the model.

[0138] III. Collaborative Iterative Closed-Loop Optimization Design in Step S5: In this embodiment, step S5 is not only used for ex-post parameter-level correction of the global load prediction model, but is designed as a closed-loop mechanism that drives the coordinated evolution of "model iteration - scheduling strategy evolution - node incentive allocation" based solely on the same trusted data source stored in the blockchain layer.

[0139] (a) The working principle of the uniqueness of trusted data sources; When executing steps S5.1 to S5.3, the smart contract does not accept any off-chain input data or manual intervention parameters. All its calculations are strictly limited to the data set that has been consensused and stored in the blockchain layer, including: the encrypted model data and its parameter hashes uploaded by each node in each iteration; all scheduling instructions generated and issued by the smart contract; and the execution feedback data and exception handling records uploaded by each node in step S4.

[0140] Since the above data is confirmed by a consensus algorithm before being written into the distributed ledger and has the characteristic of being immutable, it constitutes a unique, reliable, and auditable source of data facts.

[0141] This design avoids the problem of inconsistent sources of model training data, scheduling evaluation data and incentive evaluation data from the perspective of system structure, and eliminates the "inconsistent data standards" and "ex-post correction space" common in distributed systems.

[0142] (ii) The synchronous triggering mechanism for model iteration and incentive evaluation; Unlike conventional systems that separate model updates and incentive distribution into different management processes, in this embodiment, the smart contract triggers the following two types of operations simultaneously within the same execution cycle, based on the same batch of trusted data: Model-side operations: Following the optimization algorithm in step S5.1.2, the learning rate, number of network layers, and attention mechanism weights of the global load prediction model are jointly adjusted; Synchronously update the dynamic aggregation weights of each node in the next round of federated aggregation.

[0143] Governance side operation: According to step S5.2, score the contribution of each node's behavior within the same evaluation period; According to step S5.3, differentiated incentive allocation is performed on eligible nodes and publicized on the chain.

[0144] Since the two types of operations are executed consecutively by the same smart contract instance and in the same on-chain state, they logically form a strong consistency relationship: The data used to evaluate the "goodness" or "badness" of a model must also be the data used to evaluate the "contribution" of a node.

[0145] This synchronization mechanism avoids the problem of disconnect between model performance evaluation and incentive distribution in traditional systems, preventing nodes from seeking incentives through "short-term behavior" or "selective execution".

[0146] (III) Closed-loop feedback and self-reinforcing evolution mechanism; At the end of step S5, the smart contract synchronizes the optimized global load prediction model parameters to each node. After each node completes the model fine-tuning locally, it directly enters the prediction and parameter uploading process of the next step S2.

[0147] This creates the following closed-loop link at the system level: 1. Model optimization results directly affect the local prediction accuracy of each node in the next round; 2. Changes in prediction accuracy → These changes are recorded as reliable historical data through the execution feedback of steps S3 and S4; 3. Historical execution feedback → serves as input for node contribution scores and dynamic aggregation weight updates in step S5; 4. Incentives and weight changes → have a reverse impact on the data upload quality, execution enthusiasm, and timeliness of anomaly reporting of nodes; 5. Improved node behavior → Further improve the quality of model training data and drive further optimization of the global model.

[0148] The aforementioned closed loop is not maintained by external rules, but is automatically maintained by the endogenous coupling relationship between model performance, incentive benefits and node behavior, forming a data-driven self-reinforcing system.

[0149] (iv) The manifestation of creative technical effects; Through the above design, this embodiment achieves the following technical effects in step S5 that differ from conventional technical solutions: 1. Deep integration of model evolution and system governance: The traditionally separate model optimization process and node incentive mechanism are unified into the same smart contract, the same trusted data source and the same execution cycle, so as to avoid conflicts between governance rules and technical goals.

[0150] 2. Endogenous solution to distributed collaboration dynamics: The prediction accuracy, execution quality and anomaly reporting behavior of nodes directly affect their long-term benefits in model training and scheduling resources, thus solving the problem of distributed nodes "free-riding" and passive participation from a mechanism perspective.

[0151] 3. Adaptive guarantee of long-term system stability: As the running time increases, the improvement of model quality and the optimization of node behavior promote each other, enabling the system to maintain prediction accuracy and scheduling robustness even under changes in load patterns and increased environmental disturbances.

[0152] 4. The evolution path model parameter changes, incentive results, and node rankings are all transparent, auditable, and non-repudiable and are stored on the blockchain, making the system's evolution process traceable and meeting the needs of regulatory and operational auditing.

[0153] III. Technical Effects of Embodiment Four: 1. Millisecond-level local response and adaptive exception handling during scheduling execution; 2. Reliable feedback and traceability of responsibility throughout the entire scheduling process; 3. Adaptive optimization of global model hyperparameters based on real-world operational data; 4. Drive long-term, high-quality participation of nodes through incentive mechanisms.

[0154] This led to the development of a rolling optimization scheduling system for voltage regulators that features reliable data, an evolvable model, a closed-loop scheduling mechanism, and incentive-based collaboration. This significantly improved the system's prediction accuracy, robustness, and engineering practical value under complex load conditions.

[0155] The above are merely preferred embodiments of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principle of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A rolling optimization scheduling method for voltage regulators based on load forecasting, characterized in that, Includes the following steps: Step S1: Each regional voltage regulator node completes registration at the blockchain layer and obtains a unique node identifier; The smart contract deployed on the blockchain layer includes federated aggregation rules, scheduling compliance conditions, and node contribution rules; each node initializes a local load prediction model and stores the initial parameters of the local load prediction model on the blockchain layer. Step S2: Each node obtains local prediction results based on the data collected by the perception layer and using the local load prediction model. The parameters of the local load forecasting model and the local forecasting results are encrypted using a homomorphic encryption algorithm to generate encrypted model data and upload it to the blockchain layer. Step S3: The smart contract verifies the received encrypted model data; performs federated aggregation on the verified data according to the federated aggregation rules to generate global load prediction model parameters and global prediction results; and generates scheduling instructions based on the global prediction results and the scheduling compliance conditions and sends them to the corresponding nodes. Step S4: Each node receives and executes the scheduling instruction. During the execution process, the situational awareness module monitors for anomalies and makes adaptive adjustments. After execution, execution feedback data containing actual load and status information is generated and uploaded to the blockchain layer for storage. Step S5: The smart contract iteratively optimizes the parameters of the global load prediction model based on the encrypted model data, scheduling instructions, and execution feedback data stored in the blockchain layer; calculates the contribution score of each node according to the node contribution rules and performs incentive allocation; and synchronizes the optimized global load prediction model parameters to each node to update the local load prediction model of each node.

2. The voltage regulator rolling optimization scheduling method based on load forecasting according to claim 1, characterized in that, Step S1 includes: Step S1.1, Node Registration and Information Storage: Each regional voltage regulator node submits a registration request to the blockchain layer. The registration request includes at least the node device model, load capacity limit, safe operation threshold, and historical scheduling record hash value. After verifying the registration request, the blockchain layer assigns a unique node identifier to each node and stores the basic node information, including the node device model, load capacity limit, safe operation threshold, and historical scheduling record hash value, in the distributed ledger. Step S1.2, Smart Contract Rule Deployment: In the smart contract deployed on the blockchain layer, the federated aggregation rule is configured to calculate the aggregation weight based on the historical prediction accuracy of each node; the scheduling compliance conditions are configured to include a load limit threshold, an energy consumption threshold, and a response time threshold; the node contribution rule is configured to be a weighted evaluation based on four dimensions: data quality, prediction accuracy, execution strength, and timeliness of anomaly reporting. Step S1.3, Local Model Initialization and Storage: Each node initializes the input feature range of the local load prediction model based on the load carrying capacity limit and safe operation threshold in the node basic information; the local load prediction model is constructed using a deep learning model architecture, and the initial parameters of the deep learning model architecture are used to generate initial parameter hash values, and the initial parameter hash values ​​are associated with the unique node identifier and stored in the blockchain layer.

3. The rolling optimization scheduling method for voltage regulators based on load forecasting according to claim 1, characterized in that, Step S2 includes: Step S2.1, Multi-source data acquisition and fusion: The perception layer of each node acquires local load data, equipment operating status data and environmental data in real time; wherein, the equipment operating status data includes temperature, pressure and wear degree, and the environmental data includes humidity, air pressure and weather warning information; the local load data, equipment operating status data and environmental data are timestamped and fused to form fused feature data for model input; Step S2.2, Adaptive Rolling Forecast: Each node inputs the fused feature data into the local load forecasting model for forward calculation to obtain the local forecast result for the first time period in the future; wherein, the local load forecasting model is a long short-term memory network model based on an attention mechanism; the length of the first time period is dynamically adjusted according to historical forecast deviations or weather warning information in the environmental data; Step S2.3, Homomorphic Encryption and Data Encapsulation: The Paillier homomorphic encryption algorithm is used to encrypt the parameters of the local load forecasting model and the local forecasting results respectively, generating encrypted parameters and encrypted forecasting results; the encrypted parameters, the encrypted forecasting results, the unique node identifier of the corresponding node, the current timestamp, and the confidence assessment value of this forecast are encapsulated into a standardized data packet to generate the encrypted model data; Step S2.4, Triggered Trusted Evidence Storage: The encrypted model data is uploaded to the blockchain layer; after the smart contract in the blockchain layer detects the upload event, it automatically triggers the parameter receiving logic, parses the standardized data packet, verifies the validity of the unique node identifier, and associates and stores the encrypted parameters with the hash value of the encrypted prediction result, the timestamp, and the confidence assessment value in the distributed ledger, thus completing the evidence storage for this upload.

4. The rolling optimization scheduling method for voltage regulators based on load forecasting according to claim 1, characterized in that, In step S3, the smart contract verifies the received encrypted model data, specifically including: Step S3.1.1, Format and Permission Verification: The smart contract parses the encrypted model data, verifies whether its data format conforms to the preset encryption parameter format specification, and verifies whether the node identifier that uploaded the encrypted model data exists in the list of legitimate nodes registered in the blockchain layer. Step S3.1.2, Encryption strength and confidence verification: The smart contract verifies whether the homomorphic encryption algorithm type and key length used in the encrypted model data reach the preset security strength threshold, and determines whether the current prediction confidence assessment value contained in the encrypted model data is not lower than the preset confidence threshold. Step S3.1.3, Consensus Verification and Storage: The smart contract calls the preset consensus algorithm to verify the verification process and results among the consensus nodes in the blockchain layer; when the verification passes, the verification record containing the timestamp of this verification, the hash value of the verification result and the associated node identifier is written into the distributed ledger.

5. The rolling optimization scheduling method for voltage regulators based on load forecasting according to claim 1, characterized in that, In step S3, the validated data is federated according to the federated aggregation rules to generate global load forecasting model parameters and global forecasting results, specifically including: Step S3.2.1, Dynamic weight calculation: The smart contract calculates the dynamic aggregation weight of each node in the current aggregation round based on the historical prediction accuracy records of each node stored in the blockchain layer; wherein, the historical prediction accuracy is obtained by comparing the historical local prediction results with the actual load value in the corresponding historical execution feedback data; Step S3.2.2, Secure Aggregation Calculation: In the encrypted state, the smart contract calculates the weighted average of the encrypted parameters in the verified encrypted model data according to the dynamic aggregation weight of each node, and generates encrypted global load prediction model parameters. Step S3.2.3, Result Decryption and Publication: The smart contract uses the homomorphic encryption decryption key to decrypt the encrypted global load prediction model parameters to obtain the plaintext global load prediction model parameters; based on the global load prediction model parameters, forward inference is performed to generate the global prediction result, and the summary information of the global prediction result is stored in the blockchain layer.

6. The rolling optimization scheduling method for voltage regulators based on load forecasting according to claim 2, characterized in that, In step S3, based on the global prediction result and the scheduling compliance conditions, a scheduling instruction is generated and sent to the corresponding node, specifically including: Step S3.3.1, Strategy Space Generation and Constraint Matching: The smart contract uses the global prediction result as input and combines it with the preset scheduling optimization target to generate a preliminary scheduling strategy space; each strategy in the preliminary scheduling strategy space is matched and verified with the load limit threshold, energy consumption threshold and response time threshold included in the scheduling compliance conditions, and all feasible strategy sets that meet the constraints are selected. Step S3.3.2, Optimization strategy selection: The smart contract uses a preset optimization algorithm to calculate the optimal strategy from the set of feasible strategies; wherein, the optimization algorithm takes comprehensive economic efficiency, security and stability indicators as the objective function; Step S3.3.3, Instruction Standardization and Trigger Issuance: The smart contract transforms the optimal strategy into standardized scheduling instructions, which at least include the target voltage regulator node identifier, the target opening adjustment value, and the expected execution time window; the smart contract issues the scheduling instructions to the corresponding target voltage regulator node by calling the event publishing function of the blockchain layer.

7. The rolling optimization scheduling method for voltage regulators based on load forecasting according to claim 6, characterized in that, Step S4 includes: Step S4.1, Edge computing execution and status monitoring: Each node receives and parses the scheduling instructions through the locally deployed edge computing unit, and completes the adjustment of the voltage regulator opening within the expected execution time window; at the same time, it collects the actual load data stream and equipment status data stream in real time after the execution starts. Step S4.2, Situational Awareness Anomaly Identification and Classification: Based on the actual load data stream, calculate the real-time deviation between it and the global prediction result that triggered this scheduling instruction; when the absolute value of the real-time deviation continuously exceeds the preset deviation threshold, trigger the anomaly monitoring process; the situational awareness module classifies the anomaly source according to the associated equipment status data stream and environmental data, identifying it as one of equipment failure, malicious attack or real load change; Step S4.3, Adaptive Strategy Execution for Abnormal Scenarios: If a device failure is identified, the startup process of the backup voltage regulator associated with the node is automatically triggered, and the failure event is reported to the blockchain layer; if a malicious attack is identified, the attack feature data is extracted, encrypted and uploaded to the blockchain layer for evidence storage, and a preset defensive scheduling strategy is used to overwrite the current scheduling instruction; if a real load change is identified, the rolling time window of the next round of prediction is dynamically shortened to a preset shortening value, and a non-periodic load prediction and parameter upload process is immediately triggered. Step S4.4, Execution Feedback Encapsulation and Trusted Evidence Storage: After the scheduling instruction execution cycle ends, each node generates an execution feedback data packet. The execution feedback data packet includes at least the average actual load value within the cycle, the final equipment operating status, the prediction deviation statistics, and the anomaly handling record. The data hash value of the execution feedback data packet is calculated, and the data hash value, the associated scheduling instruction identifier, and the node identifier are uploaded to the blockchain layer. After receiving the uploaded data, the smart contract automatically triggers the feedback evidence storage logic, writes the data hash value into the distributed ledger, and associates it with the corresponding scheduling instruction record.

8. The rolling optimization scheduling method for voltage regulators based on load forecasting according to claim 2, characterized in that, In step S5, the parameters of the global load prediction model are iteratively optimized, specifically including: Step S5.1.1, Trusted Data Backtracking and Extraction: During a preset low-load period, the smart contract extracts the full amount of trusted data corresponding to the current iteration cycle from the distributed ledger of the blockchain layer; the full amount of trusted data includes the encrypted model data uploaded by each node and its storage hash, all scheduling instructions issued, and all execution feedback data fed back by each node; Step S5.1.2, Parameter Adaptive Adjustment: Based on the full set of reliable data, analyze the overall prediction performance trend of the global load prediction model in the most recent iteration cycle; according to the performance trend, adjust the parameters of the global load prediction model through a preset optimization algorithm, wherein the global load prediction model parameters include at least the learning rate, the number of network layers, and the attention mechanism weights; Step S5.1.3, Dynamic update of aggregation weight: Based on the historical execution feedback data in the full trusted data, recalculate the historical prediction accuracy of each node; based on the recalculated historical prediction accuracy and the node instruction execution completion rate, update the dynamic aggregation weight of each node in the next round of federated aggregation according to the preset rules.

9. The rolling optimization scheduling method for voltage regulators based on load forecasting according to claim 1, characterized in that, In step S5, the contribution score of each node is calculated according to the node contribution rule, specifically including: Step S5.2.1, Multi-dimensional indicator quantification: The smart contract obtains raw indicator data for evaluating contribution from the evidence storage data of the blockchain layer; the raw indicator data includes: the integrity and timeliness indicators of data uploaded by each node, the deviation rate between the historical local prediction results of each node and the corresponding actual load value, the execution completion degree of each node to the scheduling instructions, and the timeliness and accuracy records of abnormal events reported by each node. Step S5.2.2, Weighted Comprehensive Score Calculation: The smart contract quantifies and scores the indicators of data quality, prediction accuracy, execution strength, and anomaly reporting according to the weight allocation preset in the node contribution rules; the quantified scores of each dimension are weighted and summed to calculate the comprehensive contribution score of each node. Step S5.2.3, Standardization and Ranking of Scores: Standardize the comprehensive contribution score and rank all nodes in descending order according to the standardized score; store the contribution list containing node identifiers, scores and rankings in the distributed ledger of the blockchain layer.

10. The rolling optimization scheduling method for voltage regulators based on load forecasting according to claim 1, characterized in that, In step S5, the incentive allocation and the synchronization of the optimized global load prediction model parameters to each node are performed, specifically including: Step S5.3.1, Execution of tiered incentive strategy: The smart contract executes differentiated incentives based on the contribution ranking results; for nodes ranked in the first preset percentage range, priority allocation of scheduling resources and priority adaptation of model iteration parameters are granted; for nodes ranked in the second preset percentage range, priority of operation and maintenance services is granted. Step S5.3.2, On-chain public disclosure of incentive results: The smart contract generates an incentive transaction record and writes it into the blockchain layer, including the incentive granting results, including the incentive type, granting node identifier and effective conditions, to complete the public disclosure; Step S5.3.3, Security Parameter Synchronization and Local Fine-tuning: The smart contract synchronizes the iteratively optimized global load prediction model parameters to each node through a secure channel; after receiving the parameters, each node uses recently collected fusion feature data to fine-tune the local load prediction model locally, thus completing the model update.

Images