A multi-type load data aggregation method and system for a hybrid microgrid

Abstract

This invention relates to the field of power information processing, and more particularly to a method and system for aggregating multi-type load data in a hybrid microgrid. The method includes: generating unique data tags and integrity evidence for each load data collected from the hybrid microgrid; writing the data tags and integrity evidence into a blockchain network via hash anchoring; hash anchoring refers to the operation of binding the feature values ​​of the data to be stored to the blockchain's evidence record using a cryptographic hash algorithm; storing the pre-processed load data locally on edge nodes, and dividing the multi-type loads into multiple load groups. When a new set of load data is received, dynamic reduction operations are performed on passive attributes based on an incremental identification matrix to update the initially clustered load groups. This approach solves the technical problem of insufficient accuracy in microgrid scheduling decisions when processing dynamic data streams in existing technologies.

Description

Technical Field

[0001] This invention relates to the field of power information processing, and in particular to a method and system for aggregating multi-type load data in a hybrid microgrid. Background Technology

[0002] Hybrid microgrids, as key carriers integrating multiple energy forms, generate massive amounts of diverse load data during their operation. How to efficiently aggregate and accurately predict and model this heterogeneous, dispersed, and privacy-sensitive load data has become a core issue in optimizing energy management strategies. During the collection, transmission, and storage of diverse load data, issues such as data loss and tampering are prone to occur due to network congestion and sensor failures, severely impacting the accuracy of upper-level data analysis and decision-making.

[0003] Existing technologies have made multi-dimensional attempts to process and predict load data from hybrid microgrids. For example, an existing technology (application publication number CN106845669A) discloses a method for predicting the annual continuous load of the power grid based on exponential smoothing. This method achieves macro-level load prediction by smoothing and extrapolating historical hourly load data. This method has certain applicability in static load prediction scenarios, but its data processing logic relies entirely on historical statistical patterns and lacks a mechanism to verify the integrity and reliability of data during transmission and storage. When applied to dynamic aggregation scenarios of multiple types of loads in hybrid microgrids, this method struggles to cope with data quality issues such as sensor anomalies and data packet loss, and cannot efficiently process incremental data streams generated by newly connected loads, leading to biases in the prediction basis.

[0004] Furthermore, while existing load data aggregation and scheduling optimization algorithms have improved in their optimization strategies, they still have many limitations. Some load allocation schemes based on heuristic algorithms, such as multi-objective allocation methods combining gravity search and particle swarm optimization, improve global search performance, but their high algorithm complexity and computational load make them difficult to meet the needs of real-time data processing. Other data matching methods based on clustering analysis divide load curves through logical clustering, but the robustness of the clustering results is insufficient, and processes such as Monte Carlo simulation introduce additional computational burdens. Some scheduling strategies based on improved bird flocking algorithms or simplified particle swarm algorithms, while balancing economy and environmental friendliness to some extent, often face a contradiction between model complexity and optimization accuracy. Moreover, when processing dynamic data streams, they are highly dependent on assumed scenarios, and the convergence speed and stability in real-time processing still need to be verified. Therefore, existing technologies suffer from insufficient accuracy in microgrid scheduling decisions due to difficulties in ensuring data quality, low incremental update efficiency, and poor real-time computation. Summary of the Invention

[0005] To address the aforementioned shortcomings or deficiencies, this invention provides a method and system for aggregating multi-type load data in hybrid microgrids, which can solve the technical problem of insufficient accuracy in microgrid scheduling decisions when processing dynamic data streams in existing technologies.

[0006] This invention provides a method for aggregating multi-type load data in a hybrid microgrid, comprising: generating unique data tags and integrity evidence for each load data collected from the hybrid microgrid; and writing the data tags and integrity evidence into the blockchain via a hash anchoring method. Hash anchoring refers to the operation of binding the feature value of the data to be stored to the blockchain storage record using a cryptographic hash algorithm. The preprocessed load data is stored locally on edge nodes, allowing the edge nodes to perform initial clustering using an improved clustering algorithm, dividing the multi-type loads into multiple load groups. When a new set of load data is connected, dynamic reduction is performed on passive attributes based on an incremental identification matrix to update the load groups divided by the initial clustering. The incremental identification matrix is ​​used to record the distinguishing relationship between newly added data objects and each attribute. Passive attributes refer to attributes whose corresponding cluster centers shift due to attribute value fluctuations after the load data is connected.

[0007] According to a second aspect, the present invention provides a multi-type load data aggregation system for a hybrid microgrid, the system relying on edge computing nodes and a blockchain network; wherein, the system includes a processing unit and a storage unit, the storage unit storing executable instructions, the processing unit integrating a data preprocessing module, an integrity verification module and a clustering analysis module, when the executable instructions are called by the processing unit, driving the edge computing node to execute any of the multi-type load data aggregation methods for a hybrid microgrid in the embodiments of the present invention.

[0008] According to a third aspect, the present invention provides an electronic device comprising: at least one processing unit; and a storage unit communicatively connected to the at least one processing unit. The storage unit stores executable instructions that can be invoked by the at least one processing unit. When the executable instructions are executed by the at least one processing unit, the at least one processing unit causes it to execute a multi-type load data aggregation method for any hybrid microgrid in the embodiments of the present invention.

[0009] According to another aspect of the present invention, a medium for storing executable instructions is provided, wherein the computer instructions are used to cause a computer to execute a multi-type load data aggregation method for any hybrid microgrid in the embodiments of the present invention.

[0010] The present invention provides a method for aggregating multi-type load data in a hybrid microgrid. This method is achieved through four core steps: generating data tags and integrity evidence for each load data, hashing and anchoring through a blockchain network, storing preprocessed load data locally on edge nodes and performing initial clustering by the edge nodes using an improved clustering algorithm, and updating the clustering results by dynamically reducing passive attributes based on an incremental identification matrix when new load data is accessed. This process involves generating unique data tags and integrity evidence for each load data set, and establishing an immutable digital fingerprint for each batch of data, laying a reliable foundation for subsequent data traceability and integrity verification. Data tags and integrity evidence are written to the distributed ledger via a blockchain network using hash anchoring, and cryptographic hash algorithms are used to bind data feature values ​​to on-chain evidence records, fundamentally eliminating the possibility of data tampering during transmission and storage. Preprocessed load data is stored locally on edge nodes, bringing data closer to computing resources and significantly shortening the physical path for data access and processing. Simultaneously, edge nodes perform initial clustering using an improved clustering algorithm, dividing multi-type loads into multiple load groups, achieving structured organization and efficient compression of heterogeneous load data. When new load data is received, dynamic reduction operations are performed on passive attributes based on the incremental identification matrix, updating only the attributes and clustering results affected by the new data, avoiding the computational overhead of full recalculation and improving response speed in incremental scenarios.

[0011] In this technical solution, the present invention addresses the problem of unstable data foundation caused by the lack of integrity constraints on multi-source heterogeneous data throughout the entire process of acquisition and transmission, as described in the background technology. By introducing a data tag generation and hash anchoring mechanism, a three-in-one data integrity assurance system of "data tag - integrity evidence - blockchain storage" is constructed, thereby providing a reliable data foundation for upper-layer applications and solving the fundamental defect of existing technologies that cannot effectively prevent data tampering and loss. To address the consequences of large load prediction deviations and reduced scheduling accuracy caused by this defect, a processing flow combining "local storage and clustering at edge nodes" and "dynamic reduction of incremental identification matrix" is established. First, the preprocessed load data is stored nearby at edge nodes and initial clustering is completed to form a stable load group structure. Then, when new load data is accessed, only passive attributes that have shifted due to attribute value fluctuations are incrementally reduced, thereby significantly reducing computational load and response latency while ensuring clustering accuracy. Therefore, the technical solution of the present invention solves the problems of large load forecasting deviation and poor real-time scheduling caused by the lack of data integrity constraints and efficient incremental update mechanism in the prior art, and improves the reliability, timeliness and resource utilization efficiency of load data aggregation in hybrid microgrids. Attached Figure Description

[0012] Figure 1 This is a flowchart of a method for aggregating multi-type load data in a hybrid microgrid according to an embodiment of the present invention; Figure 2(a) is a schematic diagram of the edge-side robust data preprocessing module of a three-layer load data security processing and intelligent aggregation architecture according to an embodiment of the present invention; Figure 2(b) is a schematic diagram of a blockchain-based load data integrity constraint model of a three-layer load data security processing and intelligent aggregation architecture according to an embodiment of the present invention. Figure 2(c) is a schematic diagram of the incremental load aggregation algorithm module of the three-layer load data security processing and intelligent aggregation architecture according to an embodiment of the present invention; Figure 3 This is a detailed execution flowchart of a cascade hydropower station collaborative scheduling optimization method according to an embodiment of the present invention; Figure 4 This is a block diagram of an electronic device used to implement embodiments of the present invention. Detailed Implementation

[0013] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0014] During the development of this invention, researchers discovered a strong coupling relationship between data integrity assurance and incremental clustering efficiency through extensive experiments and data analysis: when multi-type load data is tampered with or missing during collection and transmission, subsequent clustering analysis and incremental updates will result in significant error accumulation, leading to distorted load group partitioning; conversely, if a reliable integrity verification mechanism can be established at the data source, incremental clustering can obtain more stable clustering results with less computational overhead. Based on this relationship, this invention innovatively proposes this technical solution, utilizing the generation mechanism of data tags and integrity evidence, binding data feature values ​​to a distributed ledger through the hash anchoring operation of the blockchain network, and combining edge node local storage with an improved clustering algorithm for initial clustering. This achieves efficient aggregation processing of multi-type load data while ensuring data integrity, embodying the core concept of driving incremental update efficiency improvement with a reliable data foundation.

[0015] Specifically, the invention team discovered through experiments that traditional centralized data processing methods have technical defects: they lack means to constrain the integrity of multi-source heterogeneous data throughout the entire process of collection and transmission, resulting in an unstable data foundation; at the same time, when new loads are continuously connected, a full recalculation is required, which cannot efficiently process incremental data streams, resulting in large load prediction deviations and insufficient scheduling accuracy.

[0016] Therefore, this invention provides a method for aggregating multi-type load data in a hybrid microgrid, based on the first aspect. This method can be applied to a multi-type load data aggregation system in a hybrid microgrid (hereinafter referred to as the "system"). This system, through a collaborative architecture of edge nodes and a blockchain network, can complete local preprocessing of load data and on-chain storage of integrity evidence, achieving verifiable data integrity and dynamic updates of clustering results. Specifically, this system can be deployed in various hardware environments, including but not limited to: edge computing gateways equipped with local databases, smart distribution terminals integrating blockchain light nodes, and cloud-edge collaborative server clusters supporting distributed consensus. Figure 1 As shown, the method may include: Step S110: Generate unique data tags and integrity evidence for each load data collected from the hybrid microgrid.

[0017] The data tag is a unique identifier for a batch of payload data. It is calculated using a cryptographic hash algorithm based on the edge node number, batch number, and data collection timestamp, and is 32 bytes (256 bits) long. The integrity evidence is a cryptographic digest value used to verify whether the batch of payload data has been tampered with. It is obtained by splitting the data into multiple data blocks, constructing a hash tree (Merkle tree), and then taking the root hash value.

[0018] Specifically, the system performs the following operations on each batch of preprocessed payload data at the edge nodes: First, the data is divided into N data blocks of a fixed size (e.g., 256KB). The SHA-256 hash value of each data block is calculated. Then, a hash tree is constructed from the bottom up, ultimately obtaining the root hash value as the integrity evidence. Simultaneously, a data tag is generated based on the edge node number, batch number, and timestamp. This tag, along with the integrity evidence, is temporarily stored in a queue awaiting on-chain verification, ready for subsequent anchoring.

[0019] For example, suppose a batch of resident load data is 2 megabytes (MB) in size and is divided into 8 data blocks of 256 kilobytes (KB). The system calculates 8 hash values ​​sequentially: h1, h2, ..., h8, and then concatenates them pairwise to calculate the hash value of the parent node, finally obtaining the root hash value h_root. Meanwhile, the edge node number is EDGE001, the batch number is 20260724001, and the timestamp is 2026-07-24 10:00:00. Therefore, the data tag is SHA-256(“EDGE001”+“20260724001”+“2026-07-2410:00:00”) = “a3f2b1c4…” (32-byte hexadecimal string).

[0020] In some embodiments, the system can calculate the dynamic standard deviation of industrial, commercial and residential loads within a sliding window using the following formula (1) to quantify the fluctuation range of load data in the current period: (1) Formula (1) is the formula for calculating the dynamic standard deviation, which is used to evaluate the dispersion of load data within the sliding window period. This represents the j-th type of load (the j-th type of load refers to different load categories in a hybrid microgrid based on user electricity consumption characteristics and load curve shape). The dynamic standard deviation at the current time t; the subscript j represents the load type identifier, used to distinguish between industrial load, commercial load and residential load; L represents the length of the sliding window, which is set to 96 in this embodiment, that is, covering 96 15-minute sampling points within 24 hours; i is the time index variable within the sliding window, with a value range from 1 to L; This represents the summation operation; This represents the load power value collected at a historical time ti, in kilowatts (kW). It represents the average load within the current sliding window of the j-th type of load, and its specific calculation method is shown in formula (2).

[0021] Next, in this embodiment, the system can also calculate the average power reference value of various loads within the sliding window using formula (2): (2) Formula (2) is the formula for calculating the mean of a sliding window, which is used to determine the average level of the data when calculating the standard deviation. Let L represent the sliding window mean of the j-th type of load at the current time t; the division by L realizes the normalization process of calculating the average value; all variable definitions in formula (2) are consistent with those in formula (1).

[0022] Furthermore, in this embodiment, the system can also calculate the anomaly detection threshold for different types of loads using formula (3) to dynamically adjust the sensitivity of anomaly detection: (3) Formula (3) is the adaptive anomaly determination threshold calculation formula, which is used to automatically adjust the boundary of anomaly determination according to the load fluctuation characteristics. This represents the anomaly detection threshold for the j-th type of load at time t, in kW; This is a type coefficient, with different empirical values ​​taken based on the load fluctuation range: for industrial load settings... For commercial load settings For residential load setting Multiply by The operation amplifies the standard deviation to different degrees according to the load type, thereby generating the final anomaly judgment criteria.

[0023] Furthermore, in this embodiment, the system can also calculate the specific anomaly determination logic using formula (4), which is used to mark anomalies in the data sequence and trigger the data repair mechanism: (4) Formula (4) is the logical expression for anomaly detection. The left side of the formula... This represents the absolute deviation between the load data at the i-th historical moment within the sliding window and the window mean, in kW; (Right side of the formula) This is the threshold for determining anomalies in the current load type. When the absolute deviation value on the left is greater than the threshold on the right, this logical expression is true (output is true), and the system will mark it as such. If an outlier is identified, the average of the adjacent normal data points will be used to replace and repair it.

[0024] Therefore, by combining the above formulas (1) to (4), the system can realize a threshold adjustment mechanism that adapts to industrial and residential loads. The system uses formulas (1) and (2) to calculate the dynamic standard deviation and mean within the sliding window in real time, capturing the instantaneous fluctuation characteristics of the load data; then, it uses formula (3) to introduce a coefficient based on the load type. This mechanism adaptively adjusts the anomaly detection threshold based on the characteristics of industrial load (large fluctuations, lenient threshold) and residential load (small fluctuations, tighter threshold); finally, it performs actual anomaly detection and data cleaning using formula (4). This mechanism requires no manual intervention and can automatically adapt to the fluctuations of different load types at different times, effectively reducing the false alarm rate and improving the accuracy of anomaly detection.

[0025] In some embodiments, the system can calculate the cumulative distance of dynamic time warping (DTW) between two load curves using the following formula (5) to measure the similarity in shape between the load curves: (5) Formula (5) is the DTW distance calculation model, which is used to replace the traditional Euclidean distance and solve the problem of similarity measurement distortion caused by the time axis offset of the load curve. This represents the DTW cumulative distance value between the first load curve X and the second load curve Y; X and Y represent two load time series data to be compared, each series containing several discrete sampling points; This represents the search for the optimal path among all possible time alignment paths P that minimizes the cumulative distance; K is the total number of alignment steps (i.e., the total number of alignment point pairs) in the optimal alignment path P. This represents the k-th alignment point pair in the alignment path P; This indicates that the local distances of all aligned point pairs along the path are summed.

[0026] Next, in this embodiment, the system can also calculate the local absolute difference between adjacent sampling points in the alignment path using formula (6), as the accumulation term of the DTW distance: (6) Formula (6) is a local distance metric formula used to calculate the numerical difference between two curves at a specific alignment position. This represents the absolute difference (i.e., the local cumulative distance) between the k-th alignment point pairs in the alignment path. This represents the i-th data point on curve X, corresponding to the load sample value at a specific historical moment; This represents the j-th data point on curve Y, corresponding to the load sample value at another historical moment.

[0027] Furthermore, in this embodiment, the system can also calculate the probability of each data point being selected as the next initial cluster centroid under the K-means++ strategy using formula (7), to ensure that the initial centroids are as dispersed as possible in the load curve space: (7) Formula (7) is the initial centroid probability distribution formula for K-means++, which is used to reduce the probability of the clustering algorithm getting stuck in a local optimum. Represents the i-th load data point in the dataset. The normalized probability value of being selected as the next cluster centroid; Representing data points The shortest DTW distance to the nearest centroid among all currently selected centroids (i.e., ,in (Represents the selected centroid) This represents the square of the shortest distance; the probability of selecting a point increases quadratically as the distance increases. This represents the sum of the squares of the shortest distances from all data points in the dataset that were not selected as centroids to existing centroids, used to ensure that the sum of all candidate probabilities is normalized to 1.

[0028] Furthermore, in this embodiment, the system can also iteratively update the center position of the cluster using formula (8) to obtain the optimal center that better matches the distribution characteristics of the load curve: (8) Formula (8) is the objective function of the DTW Barycenter Averaging (DBA) algorithm, used to find the geometric center of the cluster in the DTW distance metric space. C represents the updated centroid (i.e., the DTW centroid), which is a load curve vector; This represents the i-th load curve belonging to the current cluster; This represents finding the centroid C that minimizes the sum within the parentheses; This represents the relationship between the new centroid C and the i-th load curve. The DTW distance between them. C is iteratively updated until the centroid stabilizes by calculating the mean point by point along the alignment path.

[0029] Therefore, by combining the above formulas (5) to (8), the system can use the improved DTW-K-means++ algorithm to perform high-precision clustering of multi-type load data in hybrid microgrids. Formulas (5) and (6) together construct a flexible time-warped distance metric system, which effectively identifies load curves with similar shapes but phase shifts; Formula (7) introduces an optimized K-means++ initialization strategy, which greatly improves the clustering convergence speed and reduces the risk of local optima; Formula (8) uses the DBA algorithm to replace the traditional arithmetic mean, and finds the true optimal center in the nonlinear DTW distance space. This whole set of improved mechanisms overcomes the limitations of the traditional K-means algorithm in processing time-series load data, and provides a solid data structure foundation for subsequent incremental clustering and load feature mining.

[0030] Step S120: Write the data tag and integrity evidence into the blockchain through hash anchoring.

[0031] Hash anchoring refers to the operation of binding the characteristic values ​​(data tags and integrity evidence) of the data to be stored to the blockchain's evidence record using a cryptographic hash algorithm. This operation does not write the original payload data to the blockchain, but only uploads lightweight evidence information, thereby significantly reducing storage overhead. The blockchain network uses an improved RAFT consensus mechanism (a consensus algorithm for managing distributed system log replication, designed to replace the Paxos algorithm and improve understandability through modular design), consisting of 3 to 7 validator nodes, with a block generation time of approximately 0.03 to 0.10 seconds.

[0032] Specifically, the system packages all batches of integrity evidence within a preset anchoring period (e.g., 5 minutes) into a single anchoring transaction. This transaction includes the hash value of the previous anchoring transaction, a list of integrity evidence, the edge node number, a timestamp, and a digital signature generated by the edge node using the ECDSA (Elliptic Curve Digital Signature Algorithm) algorithm (based on the secp256k1 curve). After the transaction is submitted, the verification node checks the consistency between the digital signature and the integrity evidence, and writes it to the distributed ledger after confirming that everything is correct.

[0033] For example, within a 5-minute anchoring period, the edge node collects three batches of integrity evidence (h_root1, h_root2, h_root3). The system packages this evidence along with the hash value of the previous anchoring transaction, the node ID EDGE001, and the current timestamp, and signs it using its private key. After the transaction is sent to the blockchain network, the three verification nodes verify the signature and hash value respectively, taking approximately 0.05 seconds, and then write the transaction to the ledger. At this point, any third party can verify the integrity of the payload data by querying the on-chain records.

[0034] Step S130: Store the preprocessed load data locally on the edge node, so that the edge node performs initial clustering using an improved clustering algorithm, dividing the multi-type loads into multiple load groups.

[0035] The preprocessed load data refers to the clean data sequence after sliding window adaptive anomaly detection and triple exponential smoothing. The improved clustering algorithm has three improvements over the standard K-means algorithm: first, it uses Dynamic Time Warping (DTW) distance instead of Euclidean distance to identify load curves with similar shapes but time shifts; second, it uses the K-means++ strategy to select initial centroids to avoid getting trapped in local optima; and third, it uses the DTW centroid averaging algorithm to update cluster centers, making the centroids more consistent with the distribution characteristics of the curves within the cluster.

[0036] Specifically, edge nodes read preprocessed load data from the local database. First, they use the K-means++ strategy to select k initial centroids from the dataset (k equals the number of load types, e.g., industrial, commercial, and residential). Then, for each load curve, the DTW distance to each centroid is calculated, and the curve is assigned to the group containing the nearest centroid. Next, the DBA algorithm is used to recalculate the centroids for each group, repeating the assignment and update steps until the centroids stabilize. This results in multiple load groups, each corresponding to a specific load characteristic.

[0037] For example, in a 10kV three-feeder hybrid microgrid, the system initially clustered the load data of 103 distribution transformers. After selecting three initial centroids using K-means++, the centroids stabilized after 20 iterations. The clustering results showed that the industrial load group contained 42 transformers, with its daily load curve exhibiting a bimodal characteristic, peaking at 9:00 AM and 3:00 PM; the commercial load group contained 31 transformers, with its curve exhibiting a unimodal characteristic, peaking between 12:00 PM and 2:00 PM; and the residential load group contained 30 transformers, with its curve exhibiting an evening peak characteristic, peaking between 7:00 PM and 9:00 PM. This clustering result perfectly matched the actual load types.

[0038] Step S140: When another set of load data is received, perform dynamic reduction operation on the passive attributes based on the incremental identification matrix to update the load groups of the initial clustering.

[0039] The incremental identification matrix is ​​a two-dimensional data structure used to record the distinguishing relationship between newly added data objects and their attributes. Its row index is a combination of existing and newly added objects, and its column index is an attribute. Matrix elements take the attribute name (when the attribute can distinguish between two objects) or 0 (when it cannot). Passive attributes refer to attributes whose cluster centers shift due to attribute value fluctuations after new workload data is added. Attributes whose shift exceeds a preset threshold (e.g., 5%) are marked as passive attributes. Dynamic reduction only applies to passive attributes, keeping the weights of unaffected attributes unchanged, thus avoiding a full recalculation.

[0040] Specifically, when new load data is received, the system first calculates the DTW distance between the data and each existing cluster center to determine its initial group. Then, it constructs an incremental identification matrix for existing and new data within that group. Attribute kernels are extracted from the matrix, and attribute reduction results are obtained through logical operations to identify passive attributes. Finally, dynamic reduction updates are performed only on passive attributes, the cluster centers and attribute weights of the group are recalculated, and the new data is assigned to the updated group.

[0041] For example, suppose an existing residential load group contains 30 transformers, whose characteristic attributes include: daily peak-to-valley difference (a1), weekly average load (a2), and fluctuation coefficient (a3). Add data for a new residential transformer with the attribute values: a1 = 0.5kW, a2 = 38kW, a3 = 0.15. After constructing the incremental identification matrix, the system finds that a1 and a2 can distinguish between old and new data, while a3 cannot. Further calculation of the cluster center offset follows: Δc(a1) = 8%, Δc(a2) = 6%, Δc(a3) = 2%. Since Δc(a3) < 5%, a3 is an unaffected attribute and its weight remains unchanged; a1 and a2 are passive attributes and require dynamic reduction. The system only performs reduction updates on a1 and a2, which takes about 0.2 seconds, while a full recalculation takes about 60 seconds. After the update, the newly added data is correctly assigned to the resident load group, and the cluster center is fine-tuned.

[0042] The technical solution of this embodiment provides a method for aggregating multi-type load data in a hybrid microgrid. This method is achieved through four core steps: generating data tags and integrity evidence for each load data, hashing and anchoring through a blockchain network, storing the preprocessed load data locally on the edge node and performing initial clustering by the edge node using an improved clustering algorithm, and updating the clustering results by dynamically reducing passive attributes based on an incremental identification matrix when new load data is accessed. This process involves generating unique data tags and integrity evidence for each load data set, and establishing an immutable digital fingerprint for each batch of data, laying a reliable foundation for subsequent data traceability and integrity verification. Data tags and integrity evidence are written to the distributed ledger via a blockchain network using hash anchoring, and cryptographic hash algorithms are used to bind data feature values ​​to on-chain evidence records, fundamentally eliminating the possibility of data tampering during transmission and storage. Preprocessed load data is stored locally on edge nodes, bringing data closer to computing resources and significantly shortening the physical path for data access and processing. Simultaneously, edge nodes perform initial clustering using an improved clustering algorithm, dividing multi-type loads into multiple load groups, achieving structured organization and efficient compression of heterogeneous load data. When new load data is received, dynamic reduction operations are performed on passive attributes based on the incremental identification matrix, updating only the attributes and clustering results affected by the new data, avoiding the computational overhead of full recalculation and improving response speed in incremental scenarios.

[0043] In this technical solution, this embodiment addresses the problem of unstable data foundation caused by the lack of integrity constraints on multi-source heterogeneous data throughout the entire acquisition and transmission process, as described in the background technology. By introducing a data tag generation and hash anchoring mechanism, a three-in-one data integrity assurance system of "data tag - integrity evidence - blockchain notarization" is constructed, thus providing a reliable data foundation for upper-layer applications and solving the fundamental defect of existing technologies that cannot effectively prevent data tampering and loss. To address the consequences of large load prediction deviations and decreased scheduling accuracy caused by this defect, a processing flow combining "local storage and clustering at edge nodes" and "dynamic reduction of incremental identification matrix" is established. First, the preprocessed load data is stored nearby at edge nodes and initial clustering is completed to form a stable load group structure. Then, when new load data is accessed, only passive attributes that have shifted cluster centers due to attribute value fluctuations are incrementally reduced, thereby significantly reducing computational load and response latency while ensuring clustering accuracy. Therefore, the technical solution of this embodiment solves the problems of large load forecasting deviation and poor real-time scheduling caused by the lack of data integrity constraints and efficient incremental update mechanism in the prior art, and improves the reliability, timeliness and resource utilization efficiency of hybrid microgrid load data aggregation.

[0044] In some embodiments, the system can construct an incremental identification matrix using the following formula (9) to dynamically track the differences in attributes between newly added data samples and existing historical data: (9) Formula (9) is the definition of the incremental identification matrix, which aims to select unique feature dimensions that can distinguish new samples from existing samples. This indicates that the new dataset is being used. The constructed incremental recognition matrix; The function is called the distinguishing function. When attribute a can distinguish between existing object x and newly added object y (i.e., the attribute values ​​are not equal), the function takes the value of true (or 1), otherwise it takes the value of false (or 0); a is a specific attribute in the attribute set A; U is the existing set of historical objects (the clustered load data sample set); For the newly added dynamic data sample set; f is the feature mapping function. This represents the specific characteristic value of object x on attribute a.

[0045] Next, in this embodiment, the system can also extract the non-zero elements in the matrix using formula (10) to generate an attribute kernel set for subsequent logical operations, thereby reducing the computational load: (10) Formula (10) is the attribute kernel extraction formula, which is used to quickly separate the distinguishable attributes from the incremental recognition matrix. Indicates for new samples The extracted set of attribute kernels (i.e., the discrimination function); the right side of the equation This represents the k-th attribute identifier in the matrix that satisfies the condition; the logical meaning of this formula is to start from the matrix row index (existing object). ) and column indexes (new objects) From the intersection of the terms, extract the non-zero elements of the attribute column index a to form a set.

[0046] Furthermore, in this embodiment, the system can also perform a conjunction operation on the extracted attribute kernel using formula (11) to construct a complete attribute reduction result, so as to clarify the attribute range that ultimately needs to be dynamically updated: (11) Formula (11) is the conjunctive normal form of the attribute reduction result, used to integrate the attribute kernels of multiple newly added samples. F is the final attribute reduction set; These represent the sets of independent attribute kernels extracted for the 1st to nth newly added samples; The logical AND (conjunction) operator indicates that an attribute is retained in the final reduction set F only if it belongs to the attribute kernel of all newly added samples.

[0047] Furthermore, in this embodiment, the system can also calculate the offset of the cluster centers before and after the introduction of new samples using formula (12), which serves as a quantitative basis for determining whether the attributes are affected: (12) Formula (12) is the formula for calculating the cluster center offset, which is used to quantify the impact of new data on the original cluster structure. This represents the absolute offset of the cluster center along the dimension of attribute 'a'; To include new samples Then, the cluster centers were recalculated and their values ​​on attribute a were obtained. These are the historical values ​​of the original cluster centers on attribute a; This indicates an absolute value operation, ensuring that the offset is a non-negative number.

[0048] Finally, in this embodiment, the system can also compare... and The size of the threshold is used to determine which attributes are "affected attributes", so that dynamic reduction is performed only on these attributes during incremental updates.

[0049] The attribute offset calculated by formula (12); A preset offset threshold (set to 0.05, or 5%, in this embodiment) is used to define the critical value at which a significant change occurs in the cluster centers; when If the value exceeds the threshold, the system will mark attribute a as an "affected attribute" (the weight needs to be recalculated during the reduction process); otherwise, it will mark it as an "unaffected attribute" (the original weight will remain unchanged during the reduction process).

[0050] Therefore, by combining the above formulas (9) to (12), the system can realize a dynamic attribute reduction mechanism based on the incremental identification matrix. The system uses formulas (9) and (10) to quickly locate the feature dimensions that differ from historical data in the newly added load data; then it uses formula (11) to integrate these differing dimensions into a unified attribute reduction set; subsequently, it uses formula (12) to accurately calculate the change in cluster centers, and uses this as a criterion to select the "affected attributes" that truly need to be dynamically updated. This mechanism avoids the high cost of repeatedly calculating the entire historical data in traditional methods, and improves the real-time performance and computational efficiency of incremental clustering and load data processing.

[0051] In another embodiment, Tables 1(a) to 1(d) show the quantitative performance evaluation results of the adaptive data processing and privacy protection method for multi-agent collaborative scenarios in hybrid microgrids proposed in this invention in actual operation.

[0052] Tables 1(a) and 1(b) compare the response performance indicators of the proposed method and the conventional fixed threshold method in the anomaly detection process from different levels, including the engineering side, regional agent side, and community side. The data shows that in scenarios with large fluctuations in industrial load, the proposed method stably controls the trigger delay for anomaly detection within the range of 0.1 to 0.2 seconds, compared to the traditional method's delay of 0.41 to 0.52 seconds, representing an efficiency improvement of over 50%. Furthermore, in scenarios with low fluctuations in residential load, the proposed method further reduces the false positive rate to approximately 7.0%, superior to the traditional method's false positive rate of up to 83.2%. This result strongly demonstrates that the adaptive threshold adjustment mechanism based on the sliding window dynamic standard deviation can effectively overcome the applicability limitations of fixed thresholds under different load characteristics, enhancing the system's robustness in analyzing complex, multi-source, heterogeneous load data.

[0053] Furthermore, Tables 1(c) and 1(d) focus on the efficiency of cluster analysis and dynamic update performance under large-scale load data environments. Test results show that as the number of load samples to be processed gradually increases from 1000 to 10000, the method of this invention exhibits a significant linear growth advantage in both cluster convergence time and attribute reduction efficiency. In the extreme test scenario with 10000 samples, the overall system iteration count is only 420, compared to the 1350 iterations required by the traditional K-means method, reducing computational resource consumption by nearly 70%. This demonstrates that by introducing an optimization strategy combining DTW-K-means++ with an incremental identification matrix, this invention successfully solves the computational bottleneck problem faced by traditional clustering algorithms when processing high-dimensional time-series load data, achieving efficient online learning and dynamic simplification of massive load feature data, and providing strong technical support for real-time decision-making in power grid dispatch centers.

[0054] In another embodiment, Figures 2(a) to 2(c) illustrate a three-layer load data security processing and intelligent aggregation architecture based on a multi-entity collaborative scenario in a hybrid microgrid. This architecture achieves efficient data governance and privacy protection mechanisms through the deep integration of edge-side preprocessing, blockchain-based mid-layer notarization, and upper-layer incremental aggregation.

[0055] Specifically, Figure 2(a) illustrates the first-layer architecture: the edge-side robust data preprocessing module. Facing the challenges of multi-source heterogeneity brought about by industrial loads, residential loads, and new load connections, this layer integrates two core data processing mechanisms. On the one hand, to address the high volatility of industrial loads, the system employs a 3σ exponential smoothing algorithm for deep denoising, effectively suppressing the interference of sudden noise on the load curve; on the other hand, to address the slow changing trend of residential loads, a cubic exponential smoothing algorithm is used to maintain the temporal characteristics of the data. On the other hand, in order to build a lightweight data integrity defense, the system performs hash tree construction in parallel at edge nodes (hash tree construction refers to the process of dividing the preprocessed load data into multiple data blocks according to a preset size, calculating the hash value of each block, and then repeatedly concatenating them from bottom to top to obtain the root hash value as evidence of integrity), generating compact integrity evidence; at the same time, it introduces the Pedersen commitment mechanism (the Pedersen commitment mechanism refers to the process of binding the load aggregate power value with a random blind factor through elliptic curve operations to generate a privacy commitment), hiding the binding of the preprocessed sensitive aggregate power, laying a privacy foundation for subsequent on-chain evidence storage.

[0056] Furthermore, Figure 2(b) illustrates the second-layer architecture: a blockchain-based payload data integrity constraint model. This layer utilizes distributed ledger technology to address the trust issue among multiple entities. During the data upload phase, the system employs a combination of elliptic curve cryptography and symmetric encryption to anchor payload tags via on-chain hashing, ensuring the traceability and immutability of the data source. Subsequently, through the RAFT consensus verification mechanism, three verification nodes perform consistency checks on the block data. Once consensus is reached, the data is solidified into an immutable record in the distributed ledger, achieving trust transfer from the edge to the network layer.

[0057] Next, Figure 2(c) illustrates the third-layer architecture: the incremental load aggregation algorithm module. Considering the dynamic nature of load data changes in hybrid microgrids, this layer abandons the traditional full recalculation mode and introduces an efficient incremental learning mechanism. The system first uses the improved DTW-Kmeans++ algorithm to quickly perform initial clustering of the new load data; then it constructs an incremental identification matrix, intelligently identifies and removes redundant attributes that are not affected by the new data, and achieves coarse-grained dynamic reduction; finally, it outputs refined load aggregation results, directly supporting the high-precision load forecasting and power market trading decisions of the power grid dispatch center.

[0058] Therefore, through the three-layer architecture combination shown in Figures 2(a) to 2(c), the system can construct a closed-loop management system covering the entire lifecycle of data cleaning, secure storage, and intelligent analysis. This solution not only reduces data transmission bandwidth pressure through edge computing and solves the trust bottleneck in multi-entity collaboration using blockchain, but also significantly improves the real-time processing performance of massive load data through incremental aggregation algorithms, providing strong technical support for building a transparent, efficient, and secure modern smart grid.

[0059] In another embodiment, Figure 3 This paper demonstrates the detailed execution flow of a collaborative scheduling optimization method for cascade hydropower stations based on deep reinforcement learning and digital twin technology. This process can solve the multi-objective scheduling optimization problem of cascade hydropower station groups under complex hydrological environments by constructing an intelligent decision-making system that maps virtual and real data.

[0060] Specifically, the process begins with the collection, preprocessing, and storage of real-time data from various sources within the basin, including upstream hydrological stations, meteorological satellites, and market electricity pricing systems. Subsequently, the system executes two core branches in parallel: firstly, it establishes a macroscopic energy network model encompassing thermal power generation, photovoltaic power generation, and grid transmission models; secondly, using real-time inflow and grid load data, it calculates the optimal coordinated operation and scheduling plan for the upper-level cascade hydropower stations through optimization algorithms and distributes the instructions to each lower-level hydropower station for execution. This hierarchical control architecture effectively balances overall system efficiency with local execution response.

[0061] Further, the system enters the data quality control and model fusion stage. A classifier confirms the categories of the underlying feedback data, and an error correction algorithm is executed to aggregate the local objective function, ensuring the spatiotemporal consistency of multi-source heterogeneous data in the digital twin. Building on this, the core of the process shifts to constructing an intelligent decision engine based on deep neural networks: first, a deep neural network with multiple hidden and output layers is designed as a proxy model for the physical system; then, a generalized additive model method is innovatively introduced to perform interpretability analysis on the high-dimensional features extracted by the convolutional neural network, and a neural factor machine network is used to pre-train and optimize the Q-network, thereby giving the black-box model physical causal transparency.

[0062] Next, the system uses the corrected hydropower station water level data as state input and dynamically acquires key feature changes through a gradient boosting algorithm, driving continuous interaction between the underlying physical model and the top-level decision network. To overcome the distributional differences between the simulation environment and the real physical system, this embodiment constructs a detailed digital twin model and reduces the virtual-real deviation through scene optimization technology. Finally, the system uses a genetic algorithm to globally solve the final objective function (such as maximizing power generation benefits or optimal scheduling under ecological flow constraints), outputting the optimal gate opening and power generation flow commands, thus ending the process.

[0063] Therefore, through Figure 3 By implementing the illustrated process, this solution successfully constructed a hybrid augmented intelligent framework integrating physical simulation, data-driven approaches, and evolutionary computation. This framework not only transforms the scheduling of cascade hydropower stations from offline experience-based decision-making to online adaptive optimization, but also significantly improves the robustness and economy of complex nonlinear hydropower unit groups in coping with variable climate and market environments through the deep integration of deep learning and digital twins, providing a feasible technical path for the construction of modern smart hydropower systems.

[0064] In some embodiments, each load data point undergoes sliding window adaptive anomaly detection and exponential smoothing preprocessing; generating unique data labels and integrity evidence for each load data point collected from the hybrid microgrid includes: Data tags are generated based on local node identifiers, batch identifiers, and timestamps.

[0065] Among them, the local node identifier is the unique number of the edge node in the system, used to distinguish different acquisition nodes; the batch identifier is the sequence number of the data batch generated by the same node within the same time window, used to distinguish different batches; and the timestamp is the precise time record of the data acquisition moment, used to identify the time attribute of the data.

[0066] Specifically, the system concatenates the local node identifier, batch identifier, and timestamp into a string in a fixed order. Then, it performs a preset hash algorithm on this string to obtain a fixed-length hash value as a data label. This data label is unique; any two different batches of data will generate different data labels. For example, if the edge node number is EDGE001, the batch number is 20260724001, and the timestamp is 2026-07-24 10:00:00, the system concatenates these three fields into the string "EDGE001202607240012026-07-24 10:00:00", and then uses the SHA-256 algorithm to calculate the hash value, resulting in a 32-byte hexadecimal string. The string “a3f2b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1” is the data tag for this batch of load data.

[0067] The preprocessed load data is divided into multiple data blocks according to the preset data block size.

[0068] The preset data block size refers to the fixed length used by the system to divide the data, such as 256KB. A data block refers to each independent data segment obtained after division, and each data block is of equal size (the last data block may be smaller than the preset size, but it is still treated as an independent data block).

[0069] Specifically, the system reads the total number of bytes of preprocessed load data, divides it by the preset data block size, and obtains the number of data blocks N. If the total number of bytes is not divisible, the actual size of the last data block is less than the preset value, but the system still treats it as an independent data block for processing. After the segmentation operation is completed, the system obtains N consecutive data blocks, each occupying a contiguous address space in memory. For example, a batch of resident load data is 2MB in size, and the preset data block size is 256KB. 2MB = 2048KB, divided by 256KB, yields 8 data blocks. The system sequentially divides the original data into 8 256KB data blocks, named Block_1 to Block_8 respectively. If the data size is 2.1MB (2150KB), then the first 8 data blocks are each 256KB, and the last data block is 102KB (…). The system also treats it as a separate data block.

[0070] The hash value of each data block is calculated according to the preset hash algorithm, and a hash structure is constructed from bottom to top based on the hash value. The root hash value of the hash structure is used as evidence of integrity.

[0071] The preset hash algorithm refers to the cryptographic hash function selected by the system, such as SHA-256, which can convert input data of arbitrary length into a fixed-length (256-bit) output value. The hash value is the fixed-length digest value calculated for each data block using the hash algorithm. The hash structure is a binary tree data structure where the leaf nodes are the hash values ​​of each data block, the non-leaf nodes are the result of concatenating the hash values ​​of their left and right child nodes, and the root node is the top-level hash value of the entire hash structure. Integrity evidence refers to this root hash value, which uniquely identifies the complete content of the batch of payload data; any modification to the original data will cause the root hash value to change.

[0072] Specifically, the system first calculates the hash value for each of the N data blocks, obtaining N leaf node hash values ​​(h1, h2, ..., hN). Then, the system concatenates the hash values ​​of two adjacent leaf nodes, calculates the hash value of the concatenated string, and obtains the parent node hash value. This process is repeated until only a root node hash value remains. If the number of nodes in a certain layer is odd, the last node is copied and concatenated with itself before calculating its hash value. The final root hash value serves as evidence of the integrity of the batch of payload data. For example, for the above 8 data blocks, the system first calculates the SHA-256 hash value for each data block: ; ; ; Then construct the first-level parent node of the hash structure: ; ; ; ; Second-level parent node: ; ; Root node: ; This h_root serves as evidence of integrity. If someone subsequently tampers with the data in Block_3, h3 will become h3', which in turn will cause h34, h1234, and h_root to all change. The system can detect that the data has been tampered with by comparing the h_root recorded on the chain.

[0073] Therefore, according to the above implementation method, the system can generate unique and unforgeable data tags and integrity evidence for each batch of load data. Data tags ensure the uniqueness of batch identity, while integrity evidence ensures the verifiability of data content; together, they form the foundation for data integrity assurance. By uploading data tags and integrity evidence to the blockchain, the system achieves reliable management of the entire lifecycle of load data, providing a reliable data foundation for subsequent clustering analysis and scheduling optimization.

[0074] In some embodiments, data tags and integrity evidence are written to the blockchain via hash anchoring, including: According to the preset anchoring period, multiple batches of data tags and integrity evidence within the current period are packaged into hash anchored transactions and submitted to the blockchain network.

[0075] The preset anchoring period refers to the time interval between two consecutive anchoring operations pre-set by the system, measured in seconds or minutes, such as 300 seconds (5 minutes). This period is used to control the frequency and batch size of data uploaded to the blockchain. A hash-anchored transaction is a special type of blockchain transaction. Its payload includes a list of data tags for all batches within the current anchoring period, a list of integrity evidence, edge node identifiers, timestamps, and the hash value of the previous anchoring transaction. This transaction does not contain the original payload data, but only lightweight evidence information.

[0076] Specifically, at the end of each anchoring period, the system retrieves all batches of data tags and integrity evidence accumulated during that period from the queue to be uploaded to the blockchain. The system assembles this information into a transaction record according to a fixed format: the transaction header includes a version number and transaction type identifier; the transaction body includes the hash value of the previous anchoring transaction (used to form a chain structure), the batch quantity N, a list of N data tags, a list of N integrity evidences, an edge node identifier, and the current timestamp; the transaction tail includes a digital signature generated by the edge node using its private key. After assembly, the system broadcasts the transaction to all verification nodes in the blockchain network via an RPC (Remote Procedure Call) interface. For example, the preset anchoring period is set to 300 seconds. Within a 300-second period, the edge node processes three batches of payload data, generating data tags tag_1, tag_2, and tag_3, and integrity evidence proofs proof_1, proof_2, and proof_3, respectively. The hash value of the previous anchoring transaction is prev_hash="abc123...". The system packages the above information into a hash-anchored transaction: the transaction body includes prev_hash, batch number 3, tag list [tag_1, tag_2, tag_3], proof list [proof_1, proof_2, proof_3], node number EDGE001, and timestamp 2026-07-24 10:05:00. Edge nodes use the ECDSA algorithm (based on the secp256k1 curve) to calculate the digital signature of the transaction body, resulting in signature="3045022100...". The complete transaction data is approximately 2.5KB, far less than the storage overhead of directly uploading the original payload data (approximately 6MB) to the blockchain.

[0077] The hash-pegged transactions are digitally signed and their integrity evidence is verified by the verification nodes in the blockchain network. Once the verification is successful, the transactions are written into the distributed ledger.

[0078] Digital signature verification refers to the process where the verifying node uses the public key of the edge node to decrypt the digital signature in the transaction and compares it with the hash value of the transaction body to confirm that the transaction was indeed issued by the edge node and has not been tampered with. Integrity evidence consistency verification refers to the verifying node recalculating and verifying each integrity piece of evidence in the transaction: the verifying node extracts the integrity evidence for each batch from the transaction body, but the verifying node does not possess the original payload data and therefore cannot directly recalculate the hash tree root; in fact, the verifying node only verifies whether the integrity evidence itself satisfies the structural consistency of the hash tree (i.e., whether each piece of evidence is a valid 32-byte hash value). Deeper-level original data integrity verification is completed by the upper-layer application when accessing data by comparing the real-time hash value with the on-chain evidence. A distributed ledger refers to a transaction record database jointly maintained by all nodes in a blockchain network, using an append-only writing method. Each block contains a batch of transactions and the hash value of the previous block, forming an immutable chain structure.

[0079] Specifically, when a validator node receives a hash-pegged transaction, it first extracts the digital signature and transaction body from the transaction. Using the edge node's public key, it decrypts the signature to obtain a digest value and simultaneously calculates the SHA-256 hash value for the transaction body, comparing the two. If they don't match, the transaction is rejected. If they match, it further checks whether each integrity token in the transaction is a valid 32-byte hexadecimal string and whether the length of the data tag list matches the batch size. After all checks pass, the validator node adds the transaction to the pool of transactions to be packaged, awaiting consensus before writing it into the next block. The consensus mechanism uses a modified RAFT protocol, with the master node responsible for packaging blocks and slave nodes performing log replication and confirmation. When more than half of the validator nodes confirm, the block is appended to the end of the distributed ledger. For example, the blockchain network consists of 5 validator nodes (V1 to V5). Edge nodes broadcast hash-pegged transactions to all nodes. As the master node, V1 first verifies the digital signature of the transaction: it decrypts the signature using the edge node's public key to obtain the hash_expected digest value, and calculates the SHA-256 hash of the transaction body to obtain the hash_actual digest. Both are "a1b2c3...", so the verification passes. Next, it checks the integrity evidence list; all three pieces of evidence are 32-byte hexadecimal strings with correct formatting. V1 adds the transaction to the block-to-package list and sends pre-preparation messages to V2 through V5. V2 through V5 perform the same verification process, and after all verifications pass, they send confirmation messages to V1. Once V1 has collected at least three confirmation messages (more than half), it packages the transaction along with other transactions into a block, calculates the block hash value, and appends it to its local ledger. The entire process takes approximately 0.08 to 0.12 seconds. Afterward, any node can query the transaction records in this block to obtain the correspondence between the data tags and integrity evidence for each batch.

[0080] Therefore, according to the above implementation method, the system can permanently record data tags and integrity evidence in the blockchain distributed ledger by periodically packaging and hashing transactions without putting the original payload data on the blockchain. This method significantly reduces the storage pressure on the blockchain (each transaction is only about 2.5KB, while the original data is about 6MB), while ensuring the traceability and non-repudiation of data integrity. Digital signature verification ensures the authenticity of the transaction source, and integrity evidence consistency verification ensures the validity of the evidence format. Together, they construct a trusted data storage channel.

[0081] In some embodiments, the preprocessed load data is stored locally on the edge nodes, allowing the edge nodes to perform initial clustering using an improved clustering algorithm, dividing the multi-type loads into multiple load groups, including: Initial cluster centers are determined from the stored preprocessed load data based on a preset initial centroid selection strategy.

[0082] The preset initial centroid selection strategy refers to a method for selecting initial cluster centers from the dataset. This method prioritizes points that are far apart from each other as initial centroids in a probabilistic manner to reduce the probability of getting trapped in local optima.

[0083] Specifically, the system first randomly selects a data point from the preprocessed load data as the first initial cluster center. Then, for each remaining data point, the distance from that data point to the nearest centroid selected is calculated; the larger the distance, the higher the probability of it being selected as the next centroid. This process is repeated until k initial cluster centers are selected. The value of k is equal to the expected number of load types, for example, 3 (corresponding to industrial, commercial, and residential loads). For example, the system selects 3 initial cluster centers from the load data of 103 distribution transformers. First, the data of transformer number T001 is randomly selected as the first centroid. Then, the dynamic time-normalized distance from the remaining 102 transformer data to T001 is calculated, with T035 having the largest distance (value 0.85), so T035 is selected as the second centroid. Next, the distance from the remaining 101 transformers to the nearest centroid in {T001, T035} is calculated, with T072 having the largest distance (value 0.72), so it is selected as the third centroid. At this point, the three initial cluster centers were determined as the load curves corresponding to T001, T035, and T072.

[0084] The similarity between each load data point and the initial cluster center is calculated based on the dynamic time-normalized distance; each load data point is then assigned to the group containing the cluster center with the highest similarity according to the nearest-inclusion rule.

[0085] Among them, the nearest inclusion rule refers to assigning each data point to the group corresponding to the nearest cluster center, that is, selecting the cluster center with the highest similarity (smallest distance) as the affiliation.

[0086] Specifically, the system calculates the dynamic time-warped distance (VTW) to each load curve with respect to the k initial cluster centers. The VTW measures the minimum cumulative distance between two time series after flexible alignment on the time axis, accurately measuring morphological similarity even if the two curves have temporal shifts or scaling. After calculation, the system assigns each load curve to the group containing the cluster center with the smallest VTW. For example, for the transformer load curve T050, the system calculates the VTW to the three initial cluster centers: 0.23 with T001, 0.67 with T035, and 0.55 with T072. The minimum value of 0.23 corresponds to T001, therefore T050 is assigned to the group containing T001. Similarly, the system performs the assignment operation for all 103 transformers, resulting in three temporary groups: Group 1 contains 42 transformers, Group 2 contains 31 transformers, and Group 3 contains 30 transformers.

[0087] The cluster centers of each group are updated based on the dynamic time warping centroid averaging algorithm, and the inclusion and update steps are iteratively executed until the cluster centers are stable, resulting in multiple load groups.

[0088] The Dynamic Time Warping Centroid Averaging algorithm is a method for calculating the average of multiple time series. This algorithm iteratively finds a series that minimizes the sum of the dynamic time warped distances to all series within the group. Cluster center stability means that between two consecutive iterations, the change in all cluster centers is less than a preset threshold, for example, the average offset of each point on the cluster center curve is less than 0.01.

[0089] Specifically, the system calculates new cluster centers for all load curves within each group using a dynamic time-warped centroid averaging algorithm. This algorithm first initializes an average sequence (e.g., the first curve in the group), then performs dynamic time warping alignment on each curve within the group, taking the point-by-point average of the aligned curves as the new average sequence. This process is repeated until the average sequence no longer changes significantly. After obtaining the new cluster centers, the system performs the reassignment step again (redistributing each curve based on the new centroids), and then updates the centroids again. This process is repeated until the cluster centers stabilize. For example, after the first iteration, the new cluster centers for group 1 are calculated from 42 curves using the dynamic time-warped centroid averaging algorithm. During the second reassignment, T045, originally belonging to group 1, is reassigned to group 2 because its distance from the new centroid is closer to the centroid of group 2. After the third iteration, the change in all cluster centers is less than 0.005, and the system determines that the cluster centers are stable. The final result was three load groups: Group 1 contained 41 industrial load transformers, Group 2 contained 33 commercial load transformers, and Group 3 contained 29 residential load transformers. This clustering result is largely consistent with the actual load types.

[0090] Therefore, according to the above implementation method, the system can complete the initial clustering of multi-type load data locally at the edge nodes using an improved clustering algorithm. The K-means++ strategy is used to select the initial centroids, avoiding the local optima problem that may result from random initialization; dynamic time warping distance is used as a similarity measure to accurately identify load curves with similar shapes but time offsets; and the dynamic time warping centroid averaging algorithm is used to update the cluster centers, ensuring the representativeness of the centroids in terms of shape. Through iterative optimization, the system ultimately divides heterogeneous load data into load groups with clear physical meaning, providing a structured data foundation for subsequent incremental updates and load forecasting.

[0091] In some embodiments, when another set of load data is received, a dynamic reduction operation is performed on the passive attributes based on the incremental identification matrix to update the load groups of the initial clustering, including: Calculate the similarity between the new load data and each existing cluster center to determine the initial group to which the new load data belongs.

[0092] The similarity is measured using dynamic time-warped distance, where a smaller distance indicates a greater similarity in the shapes of the two load curves. Existing cluster centers refer to the centroid curves of each load group obtained in the initial clustering stage, such as the centroids of the industrial group, commercial group, and residential group.

[0093] Specifically, the system calculates the dynamic time-normalized distance between the newly added load data and each existing cluster center, identifies the cluster center with the smallest distance, and uses the group corresponding to this cluster center as the initial group to which the new data belongs. This step does not require recalculating all the data; it only requires calculating the distance between the new data and the k centroids, with a computational complexity of O(k). Where L is the length of the load curve. For example, when adding load data for a new residential transformer, the system calculates the dynamic time-normalized distance between this data and the three existing cluster centers: the distance to the industrial cluster centroid is 0.68, the distance to the commercial cluster centroid is 0.57, and the distance to the residential cluster centroid is 0.11. The minimum distance of 0.11 corresponds to the residential cluster centroid, therefore the initial cluster to which the new data belongs is the residential load cluster.

[0094] An incremental identification matrix is ​​constructed based on the differences in the values ​​of various attributes between the newly added load data and the existing load data in the initial group.

[0095] The incremental identification matrix is ​​a two-dimensional table. The row index represents the pairing of each existing load data point with a newly added load data point within the initial group, and the column index represents the various attributes of the load data (such as daily peak-to-valley difference, weekly average load, fluctuation coefficient, etc.). Each element in the matrix records whether the attribute can distinguish the two data points in the pair: if it can, the name of the attribute is entered; if it cannot, 0 is entered.

[0096] Specifically, the system first extracts the attribute value vectors of all existing load data within the initial group, as well as the attribute value vectors of newly added load data. Then, for each pair of existing and newly added data, the system compares the differences in the values ​​of each attribute. If the absolute value of the difference exceeds a preset discrimination threshold (e.g., 0.1), the attribute is considered to distinguish the two data points, and the attribute name is entered in the corresponding position in the matrix; otherwise, 0 is entered. After traversing all pairs, a complete incremental identification matrix is ​​obtained. The number of rows in the matrix represents the number of existing data points in the initial group, and the number of columns represents the number of attributes. For example, there are 30 existing transformers in the residential load group, with attributes including daily peak-to-valley difference (a1), weekly average load (a2), and fluctuation coefficient (a3). The attribute values ​​of the newly added transformer data are a1=0.5kW, a2=38kW, and a3=0.15. For the existing transformer T001 (attribute values ​​a1=0.3kW, a2=35kW, a3=0.18), the differences in each attribute are compared: a1 can be distinguished; a2 can be distinguished; Since a1 and a2 are indistinguishable, the elements in the first row of the matrix are [a1, a2, 0]. Similarly, by comparing each of the 30 existing data points, a 30-row, 3-column incremental recognition matrix is ​​finally obtained.

[0097] Identify passive attributes from the incremental identification matrix that cause the cluster centers to shift due to fluctuations in attribute values.

[0098] Passive attributes refer to attributes whose values ​​differ significantly from the existing data within the group after new data is added, causing the cluster centers to shift by more than a preset threshold (e.g., 5%) in that attribute dimension. The method for identifying passive attributes is as follows: First, extract the attribute kernel from the incremental identification matrix—those attributes that appear in all pairings (i.e., each row of the matrix contains the attribute name). These attributes have the strongest discriminative power. Then, obtain the attribute reduction results through logical operations (disjunction and conjunction), and filter out those attributes that simultaneously meet the conditions of "high frequency of occurrence in the matrix" and "large shift in cluster centers."

[0099] Specifically, the system performs attribute reduction on the incremental identification matrix: First, it identifies the set of non-zero attributes in each row of the matrix, and finds the intersection of these sets to obtain the attribute kernel. Then, it performs disjunctive logic parsing on the attribute sets of all rows in the matrix to obtain the conjunctive normal form, and then converts it to the disjunctive normal form. After introducing the attribute kernel, it obtains the final attribute reduction result. The attributes contained in this result are the passive attributes. Simultaneously, the system calculates the cluster center shift of each attribute before and after the addition of new data. If the shift exceeds 5%, it is confirmed as a passive attribute. The two methods corroborate each other. For example, attribute reduction is performed on the aforementioned 30-row, 3-column incremental identification matrix. The frequency of each attribute in the matrix is ​​counted: a1 appears 28 times, a2 appears 27 times, and a3 appears 5 times. The attribute kernel is empty (no attribute appears in all 30 rows). Through disjunctive and conjunctive logic operations, the reduction result is {a1, a2}. Simultaneously, the cluster center offset was calculated: after adding new data, the cluster center of a1 changed from 0.32kW to 0.346kW, an offset of 8.1%; a2 changed from 36.5kW to 37.2kW, an offset of 1.9%; and a3 changed from 0.165 to 0.164, an offset of 0.6%. Only a1 had an offset exceeding 5%. Combining the two methods, the passive attributes were finally identified as a1 (daily peak-to-valley difference) and a2 (weekly average load), with a1 being the primary passive attribute.

[0100] Perform dynamic reduction updates on passive attributes and reclassify the load groups to which the newly added load data belongs based on the updated attribute weights.

[0101] Dynamic reduction update refers to adjusting the attribute weights and recalculating the cluster centers only for the identified passive attributes, while keeping the original weights and cluster centers of other unaffected attributes unchanged. Attribute weights reflect the importance of the attribute in the cluster distance calculation; initially, all attribute weights are equal (all 1). After the update, the weights of passive attributes are adjusted according to their influence on the cluster centers, with greater influence resulting in a larger increase in weight.

[0102] Specifically, for each passive attribute, the system calculates the cluster center offset of that attribute after the addition of new data, and adjusts the weight of the attribute based on the offset (e.g., weight = 1 + offset percentage). Then, using only the updated passive attribute weights, the system recalculates the weighted dynamic time-normalized distance between the new data and the cluster centers of each group, and re-determines the affiliation of the new data. If the affiliation result is consistent with the initial determination, the cluster centers of that group are directly updated (only the dimensions corresponding to the passive attributes are updated); if inconsistent, the new data is transferred to a new group, triggering an incremental update for that group. For example, the identified passive attributes are a1 (daily peak-to-valley difference) and a2 (weekly average load), with offsets of 8.1% and 1.9%, respectively. The system adjusts the weight of a1 to 1.081, the weight of a2 to 1.019, and keeps the weight of a3 unchanged at 1.0. Then, the distances between the new data and the centroids of the three groups were recalculated using weighted dynamic time-normalized distance: the weighted distance to the centroid of the residential group was 0.112, to the commercial group was 0.581, and to the industrial group was 0.693. The minimum distance remained for the residential group, therefore the new data still belonged to the residential load group. The system then updated the cluster centers of the residential groups: only the a1 and a2 dimensions were updated, a1 changed from 0.32kW to 0.345kW, a2 changed from 36.5kW to 37.1kW, and a3 remained unchanged. The entire incremental update process took approximately 0.3 seconds, while a full recalculation would have taken approximately 60 seconds.

[0103] Therefore, according to the above implementation method, when new load data is accessed, the system can quickly identify the passive attributes that have the greatest impact on the clustering results through the incremental identification matrix, and only perform dynamic reduction updates on these attributes, avoiding the huge computational overhead caused by full recalculation. This method makes full use of the attribute reduction capability of rough set theory, reducing the incremental update time from minutes to sub-seconds while ensuring clustering accuracy, thus improving the real-time performance and scalability of hybrid microgrid load data aggregation.

[0104] In some embodiments, when generating unique data tags, the above method further includes: Generate privacy commitments based on commitment protocols for each batch of preprocessed load data.

[0105] A privacy commitment is a cryptographic commitment value used to "lock" the aggregated load power value within a commitment without revealing the actual value. The commitment scheme consists of two phases: the commitment phase and the opening phase. In the commitment phase, the data holder selects a random blinding factor and uses specific mathematical operations to generate a commitment value that hides the power value from the outside world but binds it to the data, making it tamper-proof. In the opening phase, the data holder provides the original power value and the blinding factor, allowing a verifier to verify whether the commitment value corresponds to the correct power value.

[0106] Specifically, while generating data tags, the system calculates the aggregated power value (i.e., the sum of power of all sampling points in that batch) for each batch of preprocessed load data. Then, the system selects a random blind factor (e.g., a 256-bit random integer) and uses the Pedersen commitment algorithm on the elliptic curve group to substitute the aggregated power value and the blind factor into the commitment function, obtaining a point on the elliptic curve as the privacy commitment. This commitment value is stored locally on the edge node along with the data tags and can be selectively proven on the blockchain. For example, the aggregated power value of a batch of resident load data is P_load_sum = 156.8kW. The system randomly generates a blind factor r = 0x7a3b... (a 64-bit hexadecimal number). Two independent generators g and h are selected on the secp256k1 elliptic curve, and the privacy commitment Commit_id = ... (Where p is the order of the elliptic curve group). The obtained commitment value is the coordinates (x, y) of an elliptic curve point, for example (0x4f2a..., 0x8b1c...). This commitment value is only displayed externally as a string of binary data, and the original 156.8kW cannot be deduced. However, if someone later claims that the aggregate power is 157.0kW, the system can verify the authenticity by opening the commitment.

[0107] When a data request is received, a zero-knowledge proof based on the range proof protocol is generated.

[0108] The Range Proof Protocol is a zero-knowledge proof protocol that allows a prover to demonstrate to a verifier that a secret value lies within a specified range without revealing the value's actual value. Zero-knowledge proofs mean that a prover can convince a verifier that a statement is true without providing any useful information. The Bulletproofs protocol used in this scheme is an efficient range proof protocol that requires no trusted setup, has a proof size of approximately 672 bytes, and its verification time is logarithmically related to the range width.

[0109] Specifically, when an upper-layer application (such as a load forecasting module or scheduling optimization module) requests a batch of load data, the data owner (i.e., the edge node or load data holder) first generates a zero-knowledge proof π_ZKP. This proof is used to demonstrate to the verification node that the aggregate power value P_load_sum of the batch of load data is within a preset legal range [P_min, P_max], for example, [0kW, 500kW]. The proof generation process is as follows: The data owner uses the Bulletproofs protocol, inputting the aggregate power value P_load_sum, the lower limit of the range P_min, the upper limit P_max, and a random blind factor r, runs the proof generation algorithm, and outputs approximately 672 bytes of proof data. This proof does not contain the specific value of P_load_sum, nor does it contain the blind factor r. For example, the preset legal power range for residential load is [0kW, 200kW]. The data owner used the Bulletproofs library, inputting P_load_sum=156.8kW, P_min=0, P_max=200, blind factor r=0x7a3b..., and ran the Prove() function, obtaining the zero-knowledge proof π_ZKP="0x1a2b3c..." (a 672-byte hexadecimal string). This proof can be publicly verified by anyone, but the specific value of 156.8kW cannot be derived from it.

[0110] Verify the consistency between zero-knowledge proofs and privacy commitments, and allow data access only after confirming data integrity.

[0111] In this context, consistency verification refers to the verification node simultaneously checking two aspects: first, whether the zero-knowledge proof π_ZKP is correct, i.e., whether it truly proves a value within a legal range; second, whether the value implied in the proof is bound to the same value as the previously uploaded privacy commitment Commit_id. Verification nodes perform these two checks simultaneously by running the verification algorithm Verify(π_ZKP, Commit_id, P_min, P_max). Successful verification means that the data owner does indeed possess a load power value within a legal range, and this value is precisely the one bound when the privacy commitment was generated; therefore, the data has not been tampered with and its origin is legitimate.

[0112] Specifically, the validator node first retrieves the privacy commitment Commit_id corresponding to the batch of data from the blockchain or local storage. Then, the validator node inputs the zero-knowledge proof π_ZKP, the privacy commitment Commit_id, the lower bound P_min, and the upper bound P_max into the verification algorithm. The verification algorithm outputs True or False. If True, the proof passes, and the validator node confirms that the aggregate power value of the batch of load data is within the legal range and the data has not been tampered with, subsequently allowing the upper-layer application to access the batch of data. If False, the data access request is rejected, and an anomaly event is logged. For example, the validator node queries the blockchain and finds the privacy commitment Commit_id = (0x4f2a..., 0x8b1c...), and receives a data access request with the accompanying zero-knowledge proof π_ZKP = "0x1a2b3c...". The validator node runs Verify(π_ZKP, Commit_id, 0, 200), outputting True. After successful verification, the validator node returns a confirmation message to the requester, allowing the requester to obtain the batch of resident load data from the edge node. The entire verification process takes approximately 0.02 to 0.04 seconds, far less than the second-level verification time required by homomorphic encryption schemes. If an attacker attempts to tamper with the load data to 200kW and forge a proof, the forged proof will fail verification because the original blind factor r is unknown, thus effectively preventing unauthorized data access.

[0113] Therefore, according to the above implementation method, the system can achieve verifiability of data integrity and legality while protecting the privacy of load data. Through the privacy commitment mechanism, the specific value of the aggregated load power is hidden, and external observers cannot deduce the original data from the committed value; through zero-knowledge scope proof, the data owner can prove to the verification node that the power value is within the legal range without disclosing the specific value; by verifying the consistency between the commitment and the proof, the system ensures that the data is not tampered with during storage and transmission. This privacy protection mechanism is particularly suitable for scenarios involving multiple stakeholders in hybrid microgrids. Industrial owners, commercial properties, and residential communities can jointly complete data aggregation and verification without exposing their own sensitive load data, achieving the dual goals of "no privacy leakage and no sacrifice of verifiability".

[0114] In some embodiments, after receiving a data access request, the above method further includes: Retrieve preprocessed payload data from local storage and retrieve corresponding integrity evidence from the blockchain based on data tags.

[0115] Local storage refers to the database built into the edge node, such as SQLite or LevelDB, used to persistently store the preprocessed payload data and its corresponding data tags. Integrity evidence is stored in the blockchain in the form of transaction records. By using the data tags as search keywords, the corresponding anchored transaction can be quickly located, and the integrity evidence can be extracted from it.

[0116] Specifically, when an upper-layer application initiates a data request, the request carries a data tag for the target batch. The edge node first queries its local database for the corresponding preprocessed load data based on the data tag; if the data exists, it is loaded into memory. Simultaneously, the edge node sends a query request to the blockchain network, containing the data tag. The blockchain verification node searches the distributed ledger for the anchored transaction containing the data tag and returns the integrity evidence stored in that transaction, i.e., the Merkle root hash value. After receiving the evidence, the edge node proceeds to the next step of comparison. For example, if the data tag is "a3f2b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1", the edge node executes the query "SELECT * FROM load_data WHERE tag='a3f2b1c4...'" in its local SQLite database, obtaining the corresponding load data sequence, containing 1440 15-minute sampling points. Simultaneously, the edge node sends a transaction query request to the blockchain node. The blockchain node retrieves the anchored transaction containing the tag from the transaction list of the latest block and returns the integrity evidence "9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f". The edge node then prepares both.

[0117] The current hash value obtained from the preprocessed load data is compared with the integrity evidence.

[0118] The current hash value refers to the root hash value obtained by the edge node after re-executing the same hash calculation process as when generating integrity evidence on the preprocessed payload data obtained locally. This calculation process includes: dividing the data into multiple data blocks according to a preset block size (256KB), calculating the hash value of each data block using the SHA-256 algorithm, constructing a hash tree from bottom to top, and finally obtaining the root hash value. The comparison refers to comparing the current hash value byte-by-byte with the integrity evidence retrieved from the blockchain.

[0119] Specifically, the edge nodes process the batch of load data in exactly the same way as the data tag generation phase. First, they read the byte stream of load data and divide it into N data blocks of 256KB each. Then, they calculate the SHA-256 hash value for each data block, obtaining a list of leaf node hash values. Next, they concatenate parent node hash values ​​pairwise from bottom to top until a unique root hash value is obtained. This root hash value is then compared byte-by-byte with the integrity evidence (also the root hash value) obtained from the blockchain. If they match perfectly, the data has not been tampered with during storage and transmission; if they do not match, the data has been modified or corrupted. For example, the resident load data obtained locally is 2MB in size and is divided into 8 data blocks of 256KB each. The edge nodes recalculate the hash value for each block: Then construct the hash tree: The integrity evidence "9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f" obtained from the blockchain is compared byte by byte. If both are "9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f", then the comparison is successful.

[0120] If the comparison is consistent, the data integrity is confirmed and the preprocessed load data is returned.

[0121] Specifically, confirming data integrity means that the edge node acknowledges that the batch of load data has not been modified by any unauthorized operations since the integrity evidence was generated, and that the data content is consistent with the original acquisition state. Returning data means that the edge node sends the preprocessed load data over the network to the requesting upper-layer application module, such as a load forecasting engine or scheduling optimization system.

[0122] Specifically, when the comparison results match, the edge node generates a confirmation record containing information such as data tag, comparison time, and verification result, and optionally writes it to the local log. Then, the edge node encapsulates the preprocessed load data in a pre-defined data format and returns it to the requester via an API interface. If the comparison is inconsistent, the edge node refuses to return the data, generates an alarm message to notify the administrator, and records the abnormal event in the blockchain for traceability. For example, after a match, the edge node encapsulates 1440 15-minute sampling points into JSON format: {"tag":"a3f2b1c4...","data":[12.3, 12.1, ..., 15.8],"unit":"kW"}, and returns it to the load forecasting module via an HTTP REST API. Upon receiving the data, the load forecasting module executes subsequent forecasting tasks based on the trusted data. If the comparison is inconsistent, the edge node returns an HTTP 403 error and records "Data integrity verification failed, data tag: a3f2b1c4..." in the log.

[0123] Therefore, according to the above implementation method, the system can achieve real-time online verification of the integrity of load data through dual comparison of local data and on-chain evidence. This verification process does not rely on a third-party trusted institution, but can be completed solely by cryptographic hash algorithms and the immutability of the blockchain. When data is accessed, the system completes integrity verification in sub-second time, ensuring that upper-layer applications always perform analysis and decision-making based on trusted data, effectively solving the technical problem mentioned in the background art where an unstable data foundation leads to large deviations in load forecasting.

[0124] According to a second aspect, the present invention provides a multi-type load data aggregation system for a hybrid microgrid, the system relying on edge computing nodes and a blockchain network; wherein, the system includes a processing unit and a storage unit, the storage unit storing executable instructions, the processing unit integrating a data preprocessing module, an integrity verification module and a clustering analysis module, when the executable instructions are called by the processing unit, driving the edge computing node to execute any of the multi-type load data aggregation methods for a hybrid microgrid in the embodiments of the present invention.

[0125] According to a third aspect, the present invention provides an electronic device comprising: at least one processing unit; and a storage unit communicatively connected to the at least one processing unit. The storage unit stores executable instructions that can be invoked by the at least one processing unit. When the executable instructions are executed by the at least one processing unit, the at least one processing unit causes it to execute a multi-type load data aggregation method for any hybrid microgrid in the embodiments of the present invention.

[0126] According to another aspect of the present invention, a medium for storing executable instructions is provided, wherein the computer instructions are used to cause a computer to execute a multi-type load data aggregation method for any hybrid microgrid in the embodiments of the present invention.

[0127] Figure 4 A schematic block diagram of an electronic device 600 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0128] like Figure 4 As shown, the electronic device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. The RAM 603 may also store various programs and data required for the operation of the electronic device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0129] Multiple components in electronic device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of displays, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows electronic device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0130] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as a method for aggregating multi-type load data in a hybrid microgrid. For example, in some embodiments, a method for aggregating multi-type load data in a hybrid microgrid can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the method for aggregating multi-type load data in a hybrid microgrid described above can be performed. Alternatively, in other embodiments, computing unit 601 may be configured by any other suitable means (e.g., by means of firmware) to perform a multi-type load data aggregation method for a hybrid microgrid.

[0131] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0132] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0133] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0134] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0135] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0136] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0137] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this invention can be achieved, and this is not limited herein.

[0138] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for aggregating multi-type load data in a hybrid microgrid, characterized in that, include: To generate unique data tags and integrity evidence for each load data collected from a hybrid microgrid; The data tag and the integrity evidence are written into the blockchain through a hash anchoring method; the hash anchoring refers to the operation of binding the feature value of the data to be stored to the blockchain evidence record using a cryptographic hash algorithm; The preprocessed load data is stored locally on the edge nodes, which then perform initial clustering using an improved clustering algorithm to divide the multi-type loads into multiple load groups. When another set of load data is received, dynamic reduction is performed on the passive attributes based on the incremental identification matrix to update the load groups divided by the initial clustering; the incremental identification matrix is ​​used to record the distinguishing relationship between the newly added data objects and each attribute; The passive attribute refers to the attribute whose corresponding cluster center shifts due to attribute value fluctuations after the load data is accessed.

2. The method according to claim 1, characterized in that, The load data undergoes sliding window adaptive anomaly detection and exponential smoothing preprocessing; the generation of unique data labels and integrity evidence for each load data collected from the hybrid microgrid includes: The data tags are generated based on the local node identifier, batch identifier, and timestamp. The preprocessed load data is divided into multiple data blocks according to a preset data block size; The hash value of each data block is calculated according to a preset hash algorithm, and a hash structure is constructed from bottom to top based on the hash value. The root hash value of the hash structure is used as the integrity evidence.

3. The method according to claim 1, characterized in that, The step of writing the data tag and the integrity evidence into the blockchain via hash anchoring includes: According to the preset anchoring period, the data tags and integrity evidence of multiple batches within the current period are packaged into hash anchoring transactions and submitted to the blockchain network. The hash-anchored transaction is digitally signed and its integrity evidence is verified by the verification nodes in the blockchain network. Once the verification is successful, it is written into the distributed ledger.

4. The method according to claim 1, characterized in that, The process of storing preprocessed load data locally on edge nodes allows these edge nodes to perform initial clustering using an improved clustering algorithm, dividing the multi-type loads into multiple load groups, including: Initial cluster centers are determined from the stored preprocessed load data based on a preset initial centroid selection strategy. The similarity between each load data and the initial cluster center is calculated based on the dynamic time-normalized distance. According to the nearest inclusion rule, each load data is assigned to the group containing the cluster center with the highest similarity; the group containing the cluster center with the highest similarity refers to the group corresponding to the cluster center with the smallest dynamic time regularization distance from the current load data; The cluster centers of each group are updated based on the dynamic time warping centroid averaging algorithm, and the inclusion and update steps are iteratively executed until the cluster centers are stable, resulting in multiple load groups.

5. The method according to claim 1, characterized in that, When another set of load data is received, the dynamic reduction operation on the passive attributes is performed based on the incremental identification matrix to update the load groups divided by the initial clustering, including: Calculate the similarity between the new load data and each existing cluster center to determine the initial group to which the new load data belongs; Based on the differences in the values ​​of each attribute between the newly added load data and the existing load data in the initial group, an incremental identification matrix is ​​constructed; Identify passive attributes from the incremental identification matrix that cause the cluster centers to shift due to attribute value fluctuations; The passive attributes are dynamically reduced and updated, and the load groups to which the newly added load data belongs are reclassified based on the updated attribute weights.

6. The method according to claim 1, characterized in that, When generating unique data labels, the method further includes: Generate a privacy commitment based on a commitment protocol for each batch of preprocessed load data; the privacy commitment is used to hide the specific value of the load aggregation power and bind that value; When a data request is received, a zero-knowledge proof based on a range proof protocol is generated; the zero-knowledge proof is used to prove that the load aggregation power is within a legal range without revealing the specific value. After verifying the consistency between the zero-knowledge proof and the privacy commitment, and confirming the data integrity, data access is permitted.

7. The method according to claim 1, characterized in that, After receiving the data retrieval request, the method further includes: The preprocessed payload data is retrieved from local storage, and the corresponding integrity evidence is retrieved from the blockchain based on the data tags. The current hash value obtained by calculating the preprocessed load data is compared with the integrity evidence; If the comparison is consistent, the data integrity is confirmed and the preprocessed load data is returned.

8. A multi-type load data aggregation system for a hybrid microgrid, characterized in that, The system relies on edge computing nodes and a blockchain network: The system includes a processing unit and a storage unit. The storage unit stores executable instructions. The processing unit integrates a data preprocessing module, an integrity verification module, and a clustering analysis module. When the executable instructions are called by the processing unit, they drive the edge computing node to execute the multi-type load data aggregation method of the hybrid microgrid as described in any one of claims 1 to 7.

9. An electronic device, characterized in that, include: At least one processing unit; and a storage unit communicatively connected to the at least one processing unit; The storage unit stores executable instructions that can be invoked by the at least one processing unit. When the executable instructions are executed by the at least one processing unit, the at least one processing unit causes the at least one processing unit to perform the method as described in any one of claims 1 to 7.

10. A medium for storing executable instructions, characterized in that, When the executable instruction is invoked by the processing unit, it causes the processing unit to perform the method as described in any one of claims 1 to 7.

Images