A photovoltaic power generation data security synchronization method based on edge cloud cooperation
Patent Information
- Application Number
- CN202611333548.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-31
- Publication Date
- 2026-10-27
AI Technical Summary
即使单个数据通过身份认证或完整性校验,也不能当然表明有关数据已被云端连续、完整地接收并实际完成持久化提交,因而可能造成边缘节点记录的数据同步状态与云端实际提交状态不一致,影响后续的数据补传、状态更新和本地数据管理
[0020]1、本发明通过在边缘节点设置连续递增的日志位置编号,并维护已确认同步位置,基于已确认同步位置选取待同步数据,构建包含身份信息、通信阶段信息、数据范围、数据数量及窗级校验信息的同步责任窗,并锁定对应数据范围,使一次同步任务具有明确的数据边界、数据归属和校验依据,为云端数据验证、持久化核验及边缘节点同步位置更新提供统一的责任单元。
Smart Images

Figure CN122994325A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of photovoltaic power generation data synchronization technology, specifically a method for secure synchronization of photovoltaic power generation data based on edge-cloud collaboration. Background Technology
[0002] As distributed photovoltaic power plants expand in scale, inverters, combiner boxes, weather sensors, and edge gateways continuously generate operational data such as power generation, equipment status, and fault alarms. To reduce cloud computing pressure and improve on-site data processing capabilities, existing technologies typically employ an edge-cloud collaborative architecture, where edge nodes complete data collection, processing, and temporary storage, and then periodically or on-demand synchronize the relevant data to the cloud. Existing solutions also achieve data recovery after weak or offline networks through edge and cloud shadows, marking of unsynchronized data, and differential data transmission; simultaneously, they enhance data security during cloud-edge communication through device authentication, data encryption, and hash verification.
[0003] However, photovoltaic power plants are typically distributed, and communication links are prone to interruptions, latency fluctuations, and data transmission anomalies. Data awaiting synchronization may be lost, duplicated, out of order, or arrive late. Existing solutions primarily focus on whether data can be transmitted, whether cloud-edge data can eventually be consistent, and whether transmitted content has been stolen or tampered with. Synchronization status is usually determined based on data transmission completion, general response information, or data discrepancies. Even if a single piece of data passes authentication or integrity verification, it does not necessarily mean that the data has been continuously and completely received by the cloud and actually persistently committed. This can lead to inconsistencies between the data synchronization status recorded by the edge node and the actual submission status in the cloud, affecting subsequent data retransmission, status updates, and local data management. Therefore, improving the reliability of data synchronization status determination between photovoltaic edge nodes and the cloud in unstable communication environments has become a technical problem that needs to be solved in the existing technology.
[0004] To address this, a secure synchronization method for photovoltaic power generation data based on edge-cloud collaboration is proposed. Summary of the Invention
[0005] The purpose of this invention is to provide a method for secure synchronization of photovoltaic power generation data based on edge-cloud collaboration. This invention improves the reliability of data synchronization status determination and compensation synchronization by collaborating with the reread verification of stored data after transaction commit and persistent closed-loop credentials.
[0006] To achieve the above objectives, the present invention provides the following technical solution:
[0007] A method for secure synchronization of photovoltaic power generation data based on edge-cloud collaboration includes: edge nodes writing photovoltaic power generation data into local logs with synchronization positions and maintaining confirmed synchronization positions.
[0008] Based on the confirmed synchronization location, select the data to be synchronized, construct a synchronization responsibility window that limits identity information, communication stage information, data range, data quantity, and window-level verification information, and lock the data range.
[0009] The synchronization responsibility window and the data to be synchronized are sent to the cloud. The cloud verifies the data to be synchronized and identifies missing and duplicate data.
[0010] The cloud writes verified data through persistent transactions. After the transaction is committed, the stored data is reread according to the data range to verify the number and continuity of synchronization positions, and cloud verification information is generated based on the reread stored data. When the verification is successful and the cloud verification information is consistent with the window-level verification information, the termination log position of the data range is determined as the cloud-committed synchronization position and a persistent closure certificate is generated; otherwise, gap information is generated.
[0011] When persistent closure credentials are matched with the synchronization responsibility window, the confirmed synchronization position is updated to the cloud-submitted synchronization position; otherwise, the confirmed synchronization position remains unchanged. When gap information is matched with the local synchronization responsibility window, data is supplemented according to the gap information.
[0012] Preferably, the edge node writes photovoltaic power generation data into a local log with a synchronization location, including: the edge node collecting photovoltaic power generation status and power data of photovoltaic equipment to form photovoltaic power generation data; formatting and encapsulating the photovoltaic power generation data to generate data records containing data content, timestamps, and unique data stream identifiers; sequentially appending the data records to the local log; assigning a continuously increasing log position number to each data record in the local log, using the log position number as the corresponding synchronization position, and using the data stream identifier as an index to record the latest written log position number and the confirmed synchronization position, respectively.
[0013] Preferably, the step of constructing a synchronization responsibility window that defines identity information, communication stage information, data range, data quantity, and window-level verification information, and locking the data range, includes: extracting the data stream identifier and the photovoltaic device identifier from the edge node as identity information, and extracting the session connection identifier as communication stage information; using the log position numbers of the first and last data records in the data to be synchronized as the start log position and end log position, respectively, to constitute the data range, and counting the total number of data records within the data range as the data quantity; generating a record-level verification value based on the content of each data record and the log position number within the data range, and summarizing the record-level verification values to generate a window-level verification commitment value as the window-level verification information; setting the attributes of all data records within the data range to read-only state to complete the locking of the data range.
[0014] Preferably, the cloud-based verification of the data to be synchronized and the identification of missing and duplicate data includes: the cloud allocating an independently bound memory sandbox as a receiving area based on the received identity information and communication stage information; verifying the content and source of the data to be synchronized based on a digital signature and hash verification mechanism, and removing data records that fail verification; verifying the log position number of the data records in the receiving area, and removing data records with duplicate log position numbers to complete the identification of duplicate data; comparing the consecutive numbers between the starting log position and the ending log position, and determining the numbers that do not match the corresponding log position number in the receiving area as missing data.
[0015] Preferably, the generation of the persistent closure credential includes: the cloud writes the verified and duplicate-free data records into the persistent storage area and establishes a persistent transaction for this write; after the persistent transaction is committed, the corresponding data records are reread from the persistent storage area according to the identity information and data range, the number of different log position numbers is counted, and the continuity of log position numbers between the starting log position and the ending log position is verified; based on the reread data records, a cloud window-level verification commitment value is recalculated and generated as cloud verification information; when the number of different log position numbers is equal to the number of data, the log position numbers are continuous, and the cloud verification information is consistent with the window-level verification information, the synchronization position corresponding to the ending log position is determined as the cloud-committed synchronization position, and a credential file carrying a cloud digital signature is generated as a persistent closure credential.
[0016] Preferably, the step of generating gap information otherwise includes: the cloud determining missing data based on the verification results of the data to be synchronized and the reread results of the stored data after the transaction is committed, and extracting the log position number corresponding to the missing data to generate a first type of responsibility window gap information; when the verification information in the cloud is inconsistent with the window-level verification information, extracting all log position numbers within the data range to generate a second type of responsibility window gap information; and after the cloud performs digital signatures on the first type of responsibility window gap information and the second type of responsibility window gap information, it sends them to the edge nodes as the gap information.
[0017] Preferably, when the persistent closure credential matches the synchronization responsibility window, updating the confirmed synchronization position to the cloud-submitted synchronization position includes: the edge node verifying the digital signature of the persistent closure credential; after successful verification, comparing the identity information, communication stage information, data range, data quantity, and window-level verification information in the credential with the locally locked synchronization responsibility window, and comparing the cloud verification information in the credential with the window-level verification information; if all the above information matches, the edge node updates the confirmed synchronization position of the corresponding data stream identifier to the cloud-submitted synchronization position in the persistent closure credential; releasing the locking state of data records between the start log position and the end log position, and releasing the corresponding local cache space.
[0018] Preferably, when the gap information matches the local synchronization responsibility window, supplementary data is transmitted based on the gap information, including: when the gap information is a first type of responsibility window gap information, the edge node extracts the data record corresponding to the missing log position in the synchronization responsibility window; when the gap information is a second type of responsibility window gap information, it extracts all data records in the synchronization responsibility window; it uses the extracted data records to construct a compensation synchronization responsibility window associated with the synchronization responsibility window and sends it to the cloud; after the cloud writes the supplementary data, it performs a reread verification of the stored data according to the data range of the synchronization responsibility window, and generates a persistent closure certificate matching the synchronization responsibility window when the verification is successful.
[0019] Compared with the prior art, the beneficial effects of the present invention are as follows:
[0020] 1. This invention sets continuously increasing log position numbers at edge nodes and maintains confirmed synchronization positions. Based on the confirmed synchronization positions, it selects data to be synchronized and constructs a synchronization responsibility window that includes identity information, communication stage information, data range, data quantity, and window-level verification information. It also locks the corresponding data range, so that a synchronization task has clear data boundaries, data ownership, and verification basis, providing a unified responsibility unit for cloud data verification, persistent verification, and edge node synchronization position updates.
[0021] 2. After verifying the data to be synchronized in the cloud, this invention writes the verified data through persistent transactions. After the transaction is committed, the actual stored data is reread according to the data range of the synchronization responsibility window to verify the number, continuity, and content of synchronization positions. When the verification is successful and the cloud verification information is consistent with the window-level verification information, the cloud has been determined to have committed the synchronization position and a persistent closure certificate is generated. This method makes synchronization confirmation no longer dependent solely on the data reception or writing results, but corresponds to the data boundary of the actual transaction submission and reread verification in the cloud, improving the reliability and verifiability of synchronization status determination.
[0022] 3. This invention associates the update of the confirmed synchronization position with the verification result of the persistent closure credential. When the credential matches the local synchronization responsibility window, the confirmed synchronization position is updated to the submitted synchronization position in the cloud, and the data lock is released. When there is data loss or verification anomaly, the confirmed synchronization position remains unchanged, and data from the corresponding log position is extracted based on the gap information to construct a compensating synchronization responsibility window. This method helps to avoid premature confirmation of data that has not completed persistent closure and reduces the repeated transmission of irrelevant data, ensuring consistency between the synchronization status of edge nodes, cloud submission results, and local data management. Attached Figure Description
[0023] Figure 1 This is a flowchart illustrating the overall solution of the present invention;
[0024] Figure 2 This is a flowchart illustrating the construction process of the edge node log and synchronization responsibility window in this invention.
[0025] Figure 3 This is a flowchart of the cloud-based data verification and closure process of the present invention;
[0026] Figure 4 This is a flowchart illustrating the edge node credential verification and compensation synchronization process of the present invention. Detailed Implementation
[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0028] Please see Figures 1 to 4 This invention provides a method for secure synchronization of photovoltaic power generation data based on edge-cloud collaboration, the technical solution of which is as follows:
[0029] A method for secure synchronization of photovoltaic power generation data based on edge-cloud collaboration includes: edge nodes writing photovoltaic power generation data into local logs with synchronization positions and maintaining confirmed synchronization positions.
[0030] Based on the confirmed synchronization location, select the data to be synchronized, construct a synchronization responsibility window that limits identity information, communication stage information, data range, data quantity, and window-level verification information, and lock the data range.
[0031] The synchronization responsibility window and the data to be synchronized are sent to the cloud. The cloud verifies the data to be synchronized and identifies missing and duplicate data.
[0032] The cloud writes verified data through persistent transactions. After the transaction is committed, the stored data is reread according to the data range to verify the number and continuity of synchronization positions, and cloud verification information is generated based on the reread stored data. When the verification is successful and the cloud verification information is consistent with the window-level verification information, the termination log position of the data range is determined as the cloud-committed synchronization position and a persistent closure certificate is generated; otherwise, gap information is generated.
[0033] When persistent closure credentials are matched with the synchronization responsibility window, the confirmed synchronization position is updated to the cloud-submitted synchronization position; otherwise, the confirmed synchronization position remains unchanged. When gap information is matched with the local synchronization responsibility window, data is supplemented according to the gap information.
[0034] Example 1:
[0035] Furthermore, the edge node writes photovoltaic power generation data into a local log with a synchronization location, including: the edge node collecting photovoltaic power generation status and power data of photovoltaic equipment to form photovoltaic power generation data; formatting and encapsulating the photovoltaic power generation data to generate data records containing data content, timestamps, and unique data stream identifiers; sequentially appending the data records to the local log; assigning a continuously increasing log position number to each data record in the local log, using the log position number as the corresponding synchronization position, and using the data stream identifier as an index to record the latest written log position number and the confirmed synchronization position, respectively.
[0036] Specifically, this embodiment uses data synchronization in a distributed photovoltaic (PV) power station as the application scenario. Edge nodes connect to PV inverters, combiner boxes, and power acquisition devices via communication interfaces to obtain one or more data points, including device operating status, output power, fault alarms, cumulative power generation, and periodic power generation. The edge nodes differentiate the data according to the PV power station, PV equipment, and data category, ensuring that different types of data generated by different PV devices form independent data streams. Log recording, synchronization location management, and synchronization responsibility window construction are performed for each data stream to avoid confusion between the synchronization states of different devices or different data categories.
[0037] Edge nodes parse and encapsulate photovoltaic (PV) power generation data according to a preset data format, converting data fields, data units, and encoding formats from different PV devices into a unified form to generate data records. Each data record includes at least data content, a timestamp, and a unique data stream identifier. The timestamp represents the data acquisition time or the time the edge node receives the data. The unique data stream identifier is generated by encoding each identifier in the order of PV power station identifier, PV device identifier, and data category identifier, using a field length-first, field value-last format. Specifically, device operating status, output power, fault alarms, cumulative power generation, and periodic power generation correspond to the respective data category identifiers. Edge nodes use the unique data stream identifier to distinguish between different PV devices and different categories of PV power generation data, and independently maintain local logs, confirmed synchronization positions, and unclosed synchronization responsibility windows for each data stream.
[0038] Edge nodes establish corresponding local logs for each data stream and append data records to the local logs sequentially according to the order in which the data records were generated. The local logs referred to in this application are used to persistently store data records appended according to their log position numbers. The local cache space is used to store temporary data generated during the synchronization responsibility window process, and the archive area is used to store historical data that has exceeded the synchronization processing stage but still needs to be retained. These storage objects are distinguished according to their logical purpose and are not limited to being located on different physical storage media.
[0039] Edge nodes assign sequentially increasing log position numbers to each data record in the same data stream. The log position number of the first data record is set to 1. For each subsequent successful write of a data record, the log position number of the previous data record is incremented by 1 to obtain the log position number corresponding to the current data record.
[0040]
[0041] in, This indicates the log position number of the current data record. This indicates the log position number of the previous data record. The log position number serves as the synchronization position for the corresponding data record. The log position number is used to permanently identify data records appended to the local log. Data content corresponding to the same log position number remains unchanged after successful writing; when data content needs to be corrected, the corrected data content is appended to the local log as a new data record, and a new log position number is assigned, without modifying the data record corresponding to the original log position number.
[0042] Edge nodes use a unique data stream identifier as an index to record the latest written log position number and confirmed synchronization position for each data stream. The latest written log position number for the corresponding data stream is updated only after a data record is successfully written to the local log. The confirmed synchronization position records the data boundary where the corresponding data stream has completed persistence closure, and is updated after the persistence closure credential verification is successful and matches the local synchronization responsibility window. Edge nodes determine data records that have not yet completed synchronization based on the latest written log position number and confirmed synchronization position, for subsequent construction of the synchronization responsibility window.
[0043] This invention encapsulates photovoltaic power generation data in a unified manner and assigns continuously increasing log position numbers to data records in each data stream. Using the data stream identifier as an index, it maintains the latest written log position number and the confirmed synchronization position respectively, so that data from different devices and different categories have clear data writing boundaries and confirmed synchronization boundaries. This provides a unified basis for selecting data to be synchronized, determining the data range of the synchronization responsibility window, and verifying the number and continuity of subsequent synchronization positions.
[0044] Further, see Figure 2 The process of constructing a synchronization responsibility window that defines identity information, communication stage information, data range, data quantity, and window-level verification information, and locking the data range, includes: extracting the data stream identifier and the photovoltaic device identifier from the edge node as identity information, and extracting the session connection identifier as communication stage information; using the log position numbers of the first and last data records in the data to be synchronized as the start log position and end log position, respectively, to constitute the data range, and counting the total number of data records within the data range as the data quantity; generating a record-level verification value based on the content of each data record and the log position number within the data range, and summarizing the record-level verification values to generate a window-level verification commitment value as the window-level verification information; and setting the attributes of all data records within the data range to read-only state to complete the locking of the data range.
[0045] Specifically, before constructing a new synchronization responsibility window, the edge node queries the corresponding data stream identifier to see if there is an unclosed synchronization responsibility window. If an unclosed synchronization responsibility window exists, the edge node will not construct a new ordinary synchronization responsibility window based on the same confirmed synchronization position, but will prioritize processing the unclosed synchronization responsibility window; when the preset retransmission conditions are met, the unclosed synchronization responsibility window will be retransmitted, or a compensation synchronization responsibility window will be constructed based on the gap information sent from the cloud.
[0046] After obtaining a persistent closure credential and updating the confirmed synchronization position in the unclosed synchronization responsibility window, the edge node selects consecutive data records with log position numbers after the updated confirmed synchronization position to construct a new synchronization responsibility window.
[0047] If no open synchronization responsibility window exists for the corresponding data stream identifier, the edge node selects data to be synchronized from the currently confirmed synchronization position, following the principle of consecutive log position numbers not exceeding the preset single-window data quantity limit. When the number of data records that have not yet been synchronized exceeds the preset single-window data quantity limit, only a segment of consecutive data records closest to the currently confirmed synchronization position is included in the current synchronization responsibility window, while the remaining data records remain in the local log. Subsequent synchronization responsibility windows are constructed only after the current synchronization responsibility window completes persistent closure and updates the confirmed synchronization position. Synchronization responsibility windows corresponding to different data stream identifiers are managed separately and can be constructed and sent in parallel. The preset single-window data quantity limit is pre-configured based on the available bandwidth of the communication link, the average data volume of a single data record, and the allowed single retransmission data volume, ensuring that the data volume of a single synchronization responsibility window is compatible with the data transmission and verification volume that the edge node and the cloud can complete within the preset synchronization period.
[0048] Edge nodes extract the data stream identifier and the corresponding photovoltaic device identifier, combining them to form the identity information of the synchronization responsibility window. Simultaneously, they determine the session connection identifier corresponding to the current synchronization responsibility window, serving as the communication stage information for distinguishing different devices, data streams, and synchronization tasks. Edge nodes maintain a corresponding session sequence number for each data stream identifier. When constructing a new synchronization responsibility window, the edge node atomically increments the session sequence number and writes the incremented number to a non-volatile storage area, using this incremented session sequence number as the session connection identifier for the current synchronization responsibility window. The session connection identifier is determined when the current synchronization responsibility window is first constructed and remains unchanged until the current synchronization responsibility window completes its persistent closure; when retransmitting the same synchronization responsibility window, the original session connection identifier is used.
[0049] Edge nodes read the log position numbers of the first and last data records in the data to be synchronized, determining them as the start and end log positions respectively, and defining the data range from the start to the end log position. The edge nodes then count the total number of data records contained within this data range to obtain the data quantity. For consecutive log position numbers, the data quantity can be expressed as:
[0050]
[0051] in, Indicates the number of data points. Indicates the starting log position. Indicates the end log position.
[0052] Edge nodes perform normalized serialization on each data record according to the log position number. Specifically, in this embodiment, the fields are arranged in the order of data stream identifier, timestamp, data category identifier, and data value. The data stream identifier and data category identifier are encoded in UTF-8, and the timestamp is uniformly converted into an 8-byte unsigned integer in milliseconds. The device operating status and fault alarm are represented by pre-configured integer encoding, the output power is uniformly converted to watts, and the cumulative power generation and cycle power generation are uniformly converted to watt-hours. After being amplified according to the data precision pre-configured for the corresponding data category, they are converted into fixed-point integers.
[0053] Each field is arranged sequentially with its length first, followed by its value. Multi-byte integers are in big-endian byte order, and the field length for null values is set to zero, thus forming a normalized byte string for the data record. Edge nodes will... The byte string obtained after normalizing and serializing a data record is denoted as Convert the corresponding log position number into an 8-byte unsigned integer string. ,according to in front, The data is then concatenated in the following order, and a record-level checksum is generated using the SHA-256 hash algorithm:
[0054]
[0055] in, Indicates the first The record-level checksum of each data record. Indicates the first The byte string formed after normalizing and serializing each data record This represents a fixed-length byte string corresponding to the log position number. This indicates byte string concatenation. This indicates a SHA-256 hash operation.
[0056] Edge nodes and the cloud are pre-configured with the same field arrangement order, character encoding, data category encoding, data unit, data precision, byte order, log position number encoding length, and hash algorithm, enabling them to generate consistent record-level checksums for the same data record. In other implementations, other normalized serialization methods and hash algorithms that allow edge nodes and the cloud to deterministically convert the same data record into the same byte string can also be used. The edge node aggregates all record-level checksums within the data range according to log position number order and performs hash calculation again to generate a window-level checksum commitment value.
[0057]
[0058] The edge node uses the window-level verification commitment value as window-level verification information, and writes the identity information, communication stage information, data range, data quantity, and window-level verification information together into the synchronization responsibility window.
[0059] After the synchronization responsibility window is constructed, the edge node sets all data records within the range from the start log position to the end log position to read-only status. This read-only status only applies to the data range already defined within the current synchronization responsibility window and does not extend with subsequent data records. Subsequent data records are still appended to the local log according to their log position numbers, but are not merged into the currently unclosed synchronization responsibility window. Before the synchronization responsibility window obtains a persistent closure certificate or completes compensation synchronization, the edge node will not delete, overwrite, or modify the content of data records within the locked range to maintain the consistency of the corresponding data range and verification results of the synchronization responsibility window.
[0060] This invention binds identity information, communication stage information, data range, and data quantity to the synchronization responsibility window, giving each synchronization task a clear data ownership and range boundary. By generating window-level verification information by numbering data content and log positions, and locking relevant data records for read-only access, this invention helps prevent changes in data content or range during synchronization. This provides a unified data boundary and verification basis for subsequent integrity verification, missing data identification, rereading of stored data after persistent transaction commits, and verification of the number and continuity of synchronization positions in the cloud.
[0061] Furthermore, the cloud-based verification of the data to be synchronized and the identification of missing and duplicate data includes: the cloud allocating an independently bound memory sandbox as a receiving area based on the received identity information and communication stage information; verifying the content and source of the data to be synchronized based on digital signature and hash verification mechanisms, and removing data records that fail verification; verifying the log position number of the data records in the receiving area, and removing data records with duplicate log position numbers to complete duplicate data identification; comparing the consecutive numbers between the starting log position and the ending log position, and determining the numbers that do not match the corresponding log position number in the receiving area as missing data.
[0062] Specifically, after receiving the synchronization responsibility window and the corresponding data to be synchronized, the cloud creates a memory sandbox independently bound to this synchronization task based on the data flow identifier, photovoltaic device identifier, and session connection identifier in the synchronization responsibility window. The memory sandbox referred to in this application is a logically isolated memory receiving area with independent data storage areas and data access boundaries, indexed by identity information and communication stage information. Data to be synchronized corresponding to different identity information or different session connection identifiers is stored in different memory sandboxes. The cloud only performs data reading, verification, and removal operations within the memory sandbox matching the corresponding index to avoid data mixing from multiple photovoltaic devices or multiple synchronization tasks.
[0063] Before sending the synchronization responsibility window and the corresponding data to be synchronized, the edge node combines the identity information, communication stage information, data range, data quantity, window-level verification information, record-level verification value corresponding to each data record, and the corresponding data to be synchronized in the synchronization responsibility window according to the preset field order and encoding format, calculates the overall data digest, and digitally signs the overall data digest using the pre-configured edge node private key.
[0064] The cloud queries the pre-configured device and edge node binding relationship based on the identity information in the synchronization responsibility window, determines the edge node that sent this synchronization responsibility window, obtains the public key corresponding to the edge node, verifies the digital signature, and recalculates the overall data digest according to the same field order and encoding format. If verification passes, the cloud continues to perform integrity verification of the data to be synchronized, identification of missing and duplicate data, and subsequent persistent transaction writes and data reread verification. If verification fails, the cloud removes the corresponding synchronization responsibility window and the data to be synchronized from the receiving area, and does not perform subsequent persistent storage, cloud verification information generation, or persistent closure credential generation. Since the edge node has not received a valid persistent closure credential or valid gap information corresponding to the synchronization responsibility window, the synchronization responsibility window remains unclosed, and the locked state of the confirmed synchronization position and corresponding data range remains unchanged. When a preset retransmission condition is met, the edge node retransmits the unclosed synchronization responsibility window. The preset retransmission condition includes not receiving a valid persistent closure credential or valid gap information corresponding to the synchronization responsibility window within a preset time limit.
[0065] For data records that have passed digital signature verification, the cloud regenerates the byte string according to the aforementioned standardized serialization rules, log position numbering encoding rules, and hash algorithm. Fixed-length bytes representing the log position number And recalculate the record-level checksum:
[0066]
[0067] in, This represents the record-level checksum recalculated in the cloud. This represents the byte string after normalization and serialization of the corresponding data record. This represents a fixed-length byte representation of the corresponding log position number. The cloud will compare the recalculated record-level checksum with the record-level checksum carried by the data to be synchronized; if the two are inconsistent, the corresponding data record is determined to have failed integrity verification and will be removed.
[0068] After source and integrity verification is completed, the cloud sorts the data records in the memory sandbox according to the log position number. For multiple data records with the same log position number, the cloud compares the corresponding record-level checksums; if the record-level checksums are the same, one data record is retained, and the remaining data records are identified as duplicates and removed; if the record-level checksums are inconsistent, the corresponding data record is identified as failing the integrity verification and removed, and the corresponding log position number is treated as a missing log position.
[0069] The cloud generates a set of consecutive numbers based on the start and end log positions in the synchronization responsibility window. This set is then compared item by item with the verified log position numbers in the memory sandbox after duplicates have been removed. Log position numbers for which no corresponding data record is found in the memory sandbox are considered missing data. Simultaneously, the cloud counts the number of valid data records and compares this count with the number of records in the synchronization responsibility window, providing a basis for subsequent assessments of the window's completeness.
[0070] This invention binds photovoltaic device identifiers, data stream identifiers, and communication phase information to independent memory sandboxes, enabling the reception of device status, output power, fault alarms, and power generation data generated by different photovoltaic devices according to corresponding data stream partitions. By combining digital signatures, hash verification, and log position number continuity comparison, the source, content changes, duplicate records, and missing records of various types of photovoltaic power generation data are identified, providing a data foundation for subsequent persistent transaction writing, rereading and verification of stored data after transaction commit, gap information generation, and synchronization status confirmation.
[0071] Furthermore, the generation of the persistent closure credential includes: the cloud writes the verified and duplicate-free data records into the persistent storage area and establishes a persistent transaction for this write; after the persistent transaction is committed, the corresponding data records are reread from the persistent storage area according to the identity information and data range, the number of different log position numbers is counted, and the continuity of log position numbers between the starting log position and the ending log position is verified; based on the reread data records, a cloud window-level verification commitment value is recalculated and generated as cloud verification information; when the number of different log position numbers is equal to the number of data, the log position numbers are continuous, and the cloud verification information is consistent with the window-level verification information, the synchronization position corresponding to the ending log position is determined as the cloud-committed synchronization position, and a credential file carrying a cloud digital signature is generated as a persistent closure credential.
[0072] Specifically, after verifying the source and integrity of the data to be synchronized and removing duplicate data, the cloud writes the retained data records in batches to the persistent storage area according to the log position number order, using the data stream identifier and log position number as a composite index. For data records in the persistent storage area that do not have the same composite index, an add write is performed; for data records that already have the same composite index, the existing data records are compared with the data records that have passed the verification according to the aforementioned normalized serialization and record-level verification rules. If the record-level verification values are consistent, no duplicate write is performed; if the record-level verification values are inconsistent, the existing data records in the persistent storage area are retained, and the existing data records are not overwritten by the current data records. After the stored data is reread, a second type of responsibility window gap information is generated according to the handling method for inconsistencies between the cloud verification information and the window-level verification information. The above add, update, or retain operations are completed within the same persistent transaction. After the persistent transaction is committed, the cloud still performs a unified reread verification of the stored data according to the data range of the original synchronization responsibility window; if the transaction has not yet been committed, has failed to commit, or is in a rollback state, no persistent closing certificate is generated.
[0073] After a persistent transaction is committed, the cloud uses the identity information and data range in the synchronization responsibility window to reread the data records corresponding to the start and end log positions from the persistent storage area. The cloud counts the number of different log position numbers in the reread data records and verifies the continuity of adjacent log position numbers one by one according to the log position number order to determine the number of data and the position continuity status of the corresponding data range in the persistent storage area.
[0074] For the reread data records, the cloud recalculates the record-level checksum and the cloud window-level checksum commitment value according to the log position number order:
[0075]
[0076] in, This represents the cloud-based window-level verification commitment value. Indicates the number of persistent storage regions The record-level verification value is recalculated for each data record. The cloud-based window-level verification commitment value serves as the cloud-based verification information.
[0077] The cloud verifies the reread data records. When the number of different log position numbers is equal to the number of data in the synchronization responsibility window, the log position numbers from the start log position to the end log position are consecutive, and the cloud verification information is consistent with the window-level verification information carried by the synchronization responsibility window, the cloud determines the synchronization position corresponding to the end log position as the cloud-committed synchronization position and generates a credential file bound to the current synchronization responsibility window. The credential file includes at least identity information, communication stage information, data range, data quantity, and the cloud-committed synchronization position. The cloud uses its private key to digitally sign the data digest of the credential file, forming a persistent closure credential; the cloud atomically writes the responsibility window closure index, stored commit version, cloud verification information, persistent closure credential, closure status, and pending send status as a persistent closure status record. The cloud only sends the persistent closure credential stored therein after the persistent closure status record is successfully written and the closure status is set to closed; if the write fails, the credential is not sent. If the credential fails to send, the pending send status is retained, and the same persistent closure credential is resent when the retry conditions are met.
[0078] It should be noted that a successful persistent transaction commit only indicates that the data records entering the transaction have been committed. If invalid or duplicate data is removed during the preceding verification, the data records entering the transaction may not cover all log positions defined by the synchronization responsibility window. Therefore, the synchronization responsibility window cannot be determined to have been closed solely based on the transaction commit result.
[0079] This invention, after a persistent transaction is committed, re-verifies the quantity and continuity of log position numbers based on the actual stored data in the persistent storage area, and generates cloud verification information based on the reread data. When the data quantity, log position continuity, and window-level verification results all meet the requirements, the synchronization position corresponding to the terminated log position is determined as the committed synchronization position in the cloud, and a persistent closure credential is generated. This method ensures that the synchronization closure state is no longer determined solely by the data write result, but corresponds to the data boundary that has actually been committed and verified by the cloud. This helps prevent premature confirmation when data has not yet been committed or the actual storage result is abnormal, and provides verifiable evidence for edge nodes to subsequently update the confirmed synchronization position.
[0080] Furthermore, the step of generating gap information otherwise includes: the cloud determining missing data based on the verification results of the data to be synchronized and the reread results of the stored data after the transaction is committed, and extracting the log position number corresponding to the missing data to generate a first type of responsibility window gap information; when the verification information in the cloud is inconsistent with the window-level verification information, extracting all log position numbers within the data range to generate a second type of responsibility window gap information; and after the cloud performs digital signatures on the first type of responsibility window gap information and the second type of responsibility window gap information, it sends them to the edge nodes as the gap information.
[0081] Specifically, the cloud determines the missing data based on the verification results of the data to be synchronized and the results of rereading the stored data after the persistent transaction is committed, and generates corresponding responsibility window gap information based on the determination results of the missing data.
[0082] When the cloud identifies missing data through continuous comparison of log position numbers, it extracts the log position numbers for which no matching data record was found within the receiving area and generates first-type responsibility window gap information in ascending order of these numbers. The first-type responsibility window gap information includes at least identity information, communication stage information, the data range of the synchronization responsibility window, and the log position number corresponding to the missing data. For example, if the data range of the synchronization responsibility window is 1001 to 1050, and no data records corresponding to log position numbers 1013, 1014, and 1032 are received, then 1013, 1014, and 1032 are written into the first-type responsibility window gap information.
[0083] After the persistent transaction is committed, the cloud verifies the log position number of the data records reread from the persistent storage area according to the data range of the synchronization responsibility window. When the number of different log position numbers is inconsistent with the number of data records or the log position number continuity verification fails, the consecutive numbers from the start log position to the end log position are compared with the log position numbers actually obtained from the reread. The log position numbers that do not match the corresponding data records are identified as missing data, and the first type of responsibility window gap information is generated accordingly.
[0084] When a persistent transaction is committed and the stored data is reread, and the cloud-generated verification information based on the reread stored data is inconsistent with the window-level verification information generated by the edge node, the cloud will write all log position numbers from the start log position to the end log position in the synchronization responsibility window into the second type of responsibility window gap information. The second type of responsibility window gap information also includes identity information, communication stage information, data range, and verification inconsistency identifier, so that the edge node can re-extract and resend all data records corresponding to the synchronization responsibility window.
[0085] When the cloud can determine the specific missing log location based on the number of log location numbers or the continuity verification results, it prioritizes generating the first type of responsibility window gap information. If the number and continuity verification of log location numbers pass, but the cloud verification information is inconsistent with the window-level verification information and the specific abnormal data record cannot be identified, the second type of responsibility window gap information is generated. If, after the data corresponding to the first type of responsibility window gap is retransmitted, there are still window-level verification inconsistencies that cannot be located, the second type of responsibility window gap information is generated.
[0086] After the first and second types of responsibility window gap information are generated, the cloud encapsulates them according to a preset data format and calculates a data digest of the gap information. The cloud uses its private key to digitally sign the data digest and sends the digital signature result along with the gap information to the edge node. After receiving the gap information, the edge node verifies the digital signature using a pre-configured cloud public key. If the verification is successful, it extracts the corresponding data record based on the log position number within the signature.
[0087] This invention determines missing data based on the verification results of the data to be synchronized and the reread results of the stored data after the persistent transaction is committed. It then generates corresponding responsibility window gap information based on different situations where the missing data is inconsistent with the window-level verification. This ensures that local data loss discovered during the receiving phase and the actual persistent storage phase can be mapped to specific log locations. Simultaneously, it enables edge nodes to distinguish between local data loss and overall responsibility window verification anomalies, thereby determining the range of data that needs to be retransmitted. Digitally signing the gap information helps reduce the risk of tampering or forgery, providing a clear and verifiable basis for subsequent compensation synchronization.
[0088] Furthermore, when the persistent closure credential matches the synchronization responsibility window, the confirmed synchronization position is updated to the cloud-submitted synchronization position. This includes: the edge node verifies the digital signature of the persistent closure credential; after successful verification, the identity information, communication stage information, data range, data quantity, and window-level verification information in the credential are compared with the locally locked synchronization responsibility window, and the cloud verification information in the credential is compared with the window-level verification information; if all the above information matches, the edge node updates the confirmed synchronization position of the corresponding data stream identifier to the cloud-submitted synchronization position in the persistent closure credential; the locking state of the data records between the start log position and the end log position is released, and the corresponding local cache space is released.
[0089] Specifically, after receiving the persistent closure credential sent from the cloud, the edge node extracts the digital signature and credential content from the credential and verifies the digital signature based on the pre-configured cloud public key. If the digital signature verification fails, the edge node determines that the persistent closure credential is invalid, keeps the confirmed synchronization position of the corresponding data stream identifier unchanged, and does not release the locked state of the data record within the synchronization responsibility window.
[0090] After successful digital signature verification, the edge node reads the identity information, communication stage information, data range, and data quantity corresponding to the locked data range based on the local index of the synchronization responsibility window, and compares them with the corresponding information recorded in the persistent closure credential. Specifically, the identity information is used to confirm the data stream identifier and photovoltaic device identifier corresponding to the credential; the communication stage information is used to confirm the session connection identifier corresponding to the credential; the data range is used to confirm the start and end log positions; and the data quantity is used to confirm the total number of data records within the data range.
[0091] When the identity information, communication stage information, data range and data quantity in the persistent closure credential are consistent with the locally locked synchronization responsibility window, the edge node determines that the persistent closure credential matches the current synchronization responsibility window, reads the cloud-submitted synchronization position in the persistent closure credential, updates the confirmed synchronization position of the corresponding data stream identifier to the cloud-submitted synchronization position, and writes the updated confirmed synchronization position into the local location status table.
[0092] After completing the synchronization position update, the edge node releases the read-only lock on all data records between the start and end log positions and releases the temporary synchronization cache formed during the current synchronization responsibility window processing. Releasing the temporary synchronization cache is not equivalent to deleting data records from the non-volatile local log. Synchronized data in the local log is managed according to a preset local retention period; data records exceeding the local retention period and no longer requiring retention release their corresponding storage space, while historical data records that need to be retained are transferred to the archive area and no longer participate in the construction of subsequent synchronization responsibility windows as data to be synchronized.
[0093] When any information in the persistent closure credential is inconsistent with the locally locked synchronization responsibility window, the edge node does not update the confirmed synchronization position and continues to maintain the locked state of the corresponding data range, in order to wait for the cloud to reissue a persistent closure credential or gap information that matches the synchronization responsibility window.
[0094] This invention verifies the digital signature and identity information, communication stage information, data range and data quantity of the persistent closure certificate item by item. This ensures that the edge node updates the confirmed synchronization position to the cloud-submitted synchronization position recorded in the certificate only when the persistent closure certificate matches the local synchronization responsibility window. This keeps the confirmed synchronization boundary of the edge node corresponding to the data boundary actually submitted in the cloud, and keeps the synchronization position update, data lock release and local cache release consistent.
[0095] Furthermore, when the gap information matches the local synchronization responsibility window, supplementary data is transmitted based on the gap information, including: when the gap information is a first type of responsibility window gap information, the edge node extracts the data record corresponding to the missing log position in the synchronization responsibility window; when the gap information is a second type of responsibility window gap information, it extracts all data records in the synchronization responsibility window; it uses the extracted data records to construct a compensation synchronization responsibility window associated with the synchronization responsibility window and sends it to the cloud; after the cloud writes the supplementary data, it performs a reread verification of the stored data according to the data range of the synchronization responsibility window, and generates a persistent closure certificate matching the synchronization responsibility window when the verification is successful.
[0096] Specifically, after receiving the gap information from the cloud, the edge node first verifies the digital signature carried in the gap information using a pre-configured cloud public key. If the digital signature verification fails, the edge node does not retransmit the data based on the gap information and maintains the confirmed synchronization position of the corresponding data stream identifier and the data lock state of the original synchronization responsibility window unchanged.
[0097] After digital signature verification is successful, the edge node parses the identity information, communication stage information, data range, and log position number from the gap information, and compares the parsing result with the locally stored synchronization responsibility window. If the comparison is consistent, the edge node keeps the confirmed synchronization position of the corresponding data stream identifier unchanged and does not advance the confirmed synchronization position to avoid data that has not yet obtained a valid persistent closure certificate being marked as having completed synchronization.
[0098] When the gap information is a first-type responsibility window gap information, the edge node extracts the log position number corresponding to the missing data recorded therein, and reads the corresponding data record from the local log using the data stream identifier and the log position number as an index. For example, when the gap information records log position numbers 1013, 1014, and 1032, the edge node only extracts the data record corresponding to the above log position numbers.
[0099] When the gap information is a second type of responsibility window gap information, the edge node re-extracts all data records within the data range from the local log according to the start log position and end log position in the gap information, so as to resend the data content corresponding to the original synchronization responsibility window as a whole.
[0100] Edge nodes construct a compensation synchronization responsibility window using the re-extracted data records. This compensation synchronization responsibility window is not used as an independent unit to advance the closure of a confirmed synchronization position; instead, it is associated with the original, unclosed synchronization responsibility window and retains the original window's identity information, communication stage information, data range, data quantity, and window-level verification information. It also records the log position number corresponding to the data to be retransmitted. The edge nodes regenerate record-level verification values for the data to be retransmitted according to the log position number order. These record-level verification values are used to verify the integrity of the retransmitted data and do not replace the window-level verification information of the original synchronization responsibility window.
[0101] After the cloud completes the source verification, integrity verification, and persistent transaction writing of the supplementary data, it still rereads all corresponding data records from the persistent storage area according to the data range of the original synchronization responsibility window. It verifies the quantity and continuity of different log position numbers and generates cloud verification information according to the verification rules of the original synchronization responsibility window. If the verification passes and the cloud verification information matches the window-level verification information of the original synchronization responsibility window, the cloud determines the termination log position of the original synchronization responsibility window as the cloud-committed synchronization position and generates a persistent closure certificate matching the original synchronization responsibility window; otherwise, it regenerates the corresponding gap information based on the reread verification results. The edge node only updates the confirmed synchronization position and releases the locked state of the corresponding data range of the original synchronization responsibility window when the persistent closure certificate matches the original synchronization responsibility window.
[0102] Edge nodes deduplicate duplicate gap information matching the same unclosed synchronization responsibility window and record the number of retransmissions. If the same gap information is still received after retransmission, retrying is performed at preset intervals. Automatic retransmission stops once the preset retry limit is reached, the original synchronization responsibility window is marked as pending diagnosis, and the confirmed synchronization position and data lock status remain unchanged. If the original synchronization responsibility window is already closed, late gap information is not processed. The preset interval and preset retry limit are configured based on the communication link quality and the data volume per window.
[0103] This invention, upon receiving gap information, maintains the confirmed synchronization position unchanged and extracts data records from the corresponding log positions based on the gap type to construct a compensation synchronization responsibility window. This allows partially missing data to be retransmitted according to the corresponding positions, and data ranges with inconsistencies can be re-verified as a whole. This method helps reduce the repeated transmission of irrelevant data and lowers the possibility of incompletely synchronized data being prematurely confirmed or released.
[0104] This invention establishes local logs with continuous synchronization positions at edge nodes and uses a synchronization responsibility window to limit the data range, data quantity, and verification criteria for each synchronization. After completing data verification, the cloud writes data through persistent transactions and rereads the stored data after the transaction is committed to verify the number, continuity, and data content of synchronization positions. When the verification passes and the cloud verification information matches the window-level verification information, the cloud confirms that the synchronization position has been committed and generates a persistent closure certificate. Edge nodes only update the confirmed synchronization position when the certificate matches the local synchronization responsibility window; otherwise, it remains unchanged and performs compensation synchronization based on the gap information. Therefore, the synchronization status of the edge nodes corresponds to the actual data boundary submitted by the cloud, reducing misjudgments of the synchronization status and improving the reliability and traceability of data synchronization and compensation synchronization.
[0105] Example 2:
[0106] Furthermore, during the storage data rereading process after the persistent transaction is committed, the cloud reads the data records within the data range in batches according to the log position number order, and continuously calculates the cloud verification information; the storage data rereading and cloud verification information calculation can be executed as an asynchronous verification task independent of the data receiving process; the cloud obtains the storage commit version corresponding to the persistent transaction, and writes the storage commit version and the cloud committed synchronization position into the persistent closure credential.
[0107] Specifically, after a persistent transaction is committed, the cloud obtains the storage commit version corresponding to the persistent transaction and uses this storage commit version to define the fixed storage view used for this reread. The cloud uses the data stream identifier and log position number range as query conditions to read data records from the start log position to the end log position in batches within the fixed storage view, in ascending order of log position number. Each batch of reads uses the same storage commit version. For each batch of read data records, the cloud generates record-level verification values sequentially according to the same normalized serialization rules and record-level verification rules as the edge nodes, and continuously inputs them into the window-level hash calculation process in the order of log position numbers to generate cloud verification information. If the selected reading node cannot yet provide the data view corresponding to the storage commit version, gap information or persistent closure credentials are not generated based on the reading result. Instead, the storage data reread verification is re-executed after the storage commit version reading conditions are met.
[0108] The stored data rereading, synchronization location verification, and cloud verification information calculation can be executed as asynchronous verification tasks independent of the data receiving process. After the persistent closure verification conditions described in Embodiment 1 are met, the cloud generates the corresponding persistent closure credential.
[0109] The storage commit version can be a database transaction commit sequence number, a distributed storage commit version number, or a monotonically increasing commit identifier generated in the cloud. The cloud writes the identity information, communication stage information, data range, data quantity, cloud-committed synchronization position, and storage commit version into the credential file, and digitally signs the credential file to form a persistent closed credential.
[0110] This invention reduces the memory usage caused by loading large amounts of data at once by reading persistent storage data in batches and continuously calculating cloud verification information. By asynchronously executing the rereading and verification tasks of stored data and associating the storage submission version with the persistent closure certificate, the persistent closure result can be further correlated with the specific cloud submission status, thus improving the traceability of the synchronization result.
[0111] Furthermore, before sending the synchronization responsibility window and the corresponding data to be synchronized, the edge node writes the identity information, communication stage information, data range, data quantity, window-level verification information, and data range locking status of the synchronization responsibility window into a non-volatile storage area to form a recovery anchor point. When the edge node restarts, it reads the recovery anchor point that has not yet been cleared and restores the locking status of the corresponding data record according to the data range. When it receives a persistent closure certificate that matches the recovery anchor point, it updates the confirmed synchronization position to the cloud-committed synchronization position in the persistent closure certificate and clears the recovery anchor point. Otherwise, it keeps the confirmed synchronization position unchanged and resends the corresponding synchronization responsibility window according to the recovery anchor point or constructs a compensation synchronization responsibility window according to the gap information.
[0112] Specifically, after completing the construction of the synchronization responsibility window and locking the data range, the edge node generates a responsibility window index for the synchronization responsibility window. The responsibility window index can be formed by combining the data flow identifier, session connection identifier, start log position, and end log position, and is used to associate data records in the synchronization responsibility window, recovery anchor point, and local log.
[0113] Edge nodes write responsibility window indexes, identity information, communication stage information, data range, data quantity, window-level verification information, and lock status into a non-volatile storage area to form a recovery anchor. The non-volatile storage area can be the edge node's local database, solid-state storage, or other storage area capable of retaining data after power failure.
[0114] The recovery anchor point is saved using an atomic write method. The edge node only sends the synchronization responsibility window and the corresponding data to be synchronized to the cloud after receiving the successful write information of the recovery anchor point; if the recovery anchor point write fails, the edge node does not send the corresponding data to avoid the situation where the cloud has already received the data but the edge node is unable to restore the state of the synchronization responsibility window.
[0115] When an edge node experiences a power outage, process anomaly, or restart, it scans the non-volatile storage area for unclosed recovery anchors. Based on the data stream identifier and data range in the recovery anchor, the edge node reads the corresponding data record from the local log and restores the data records within the range from the start log position to the end log position to a read-only state, while maintaining the confirmed synchronization position of the corresponding data stream identifier unchanged.
[0116] After receiving the persistent closure credential, the edge node first atomically writes the persistent closure credential to a non-volatile storage area, and then verifies the digital signature of the credential. Upon successful verification, the edge node reads the locked local log data according to the data range in the recovery anchor, recalculates the window-level verification information, and compares the identity information, communication stage information, data range, data quantity, and window-level verification information in the credential with the recovery anchor and the recalculated result. If the comparison matches and the currently confirmed synchronization position is before the starting log position of the data range, the confirmed synchronization position is persistently updated to the cloud-committed synchronization position; if the confirmed synchronization position is already equal to the cloud-committed synchronization position, the process is not repeated, and only data unlocking and recovery anchor cleanup are continued. After the confirmed synchronization position update is successful, the locking state of the corresponding data record is released, and finally, the recovery anchor is marked as closed and cleared. If any step fails, the recovery anchor is retained, and the edge node continues execution from the unfinished step upon restart.
[0117] When an edge node does not save a valid persistent closure credential, it reconstructs the original synchronization responsibility window based on the recovery anchor, retains the communication stage information saved in the recovery anchor, and sends the reconstructed original synchronization responsibility window to the cloud. If gap information has been received, the edge node extracts the data record at the corresponding log position according to the gap information, constructs a compensation synchronization responsibility window, and records the communication stage information corresponding to the current compensation synchronization task. The recovery anchor is cleared after the confirmed synchronization position identified by the corresponding data stream is updated to the submitted synchronization position in the cloud; until then, it remains in an unclosed state.
[0118] This invention saves the responsibility window information and data lock status as recovery anchors before sending the synchronization responsibility window, enabling edge nodes to recover synchronization tasks that have not yet been completed after power failure, process abnormality, or restart. This method helps reduce data range mismatch caused by the loss of responsibility window information in the running memory and provides a recoverable state basis for confirmed synchronization position updates, data lock releases, and cache releases, thereby improving the continuity of synchronization state management during edge node abnormal recovery.
[0119] Furthermore, the cloud generates a responsibility window closure index based on the identity information, communication stage information, data range, data quantity, and window-level verification information, and writes the responsibility window closure index, cloud verification information, and persistent closure credential into the persistent closure status record. When the cloud receives a synchronous responsibility window again, it queries the persistent closure status record based on the responsibility window closure index. If the queried persistent closure status record matches the identity information, communication stage information, data range, data quantity, and window-level verification information of the newly received synchronous responsibility window, the persistent closure credential in the persistent closure status record is read and resent.
[0120] Specifically, when generating the persistent closure credential for the first time, the cloud generates a responsibility window closure index based on the identity information, communication stage information, data range, data quantity, and window-level verification information in the synchronous responsibility window. This responsibility window closure index can be generated by concatenating the above fields in a preset order and then performing a hash calculation; it is used to uniquely associate synchronous responsibility windows that have completed persistent closure.
[0121] A persistent closed-state table is established in the cloud, using the responsibility window closure index as the query index. A persistent closed-state record includes at least the responsibility window closure index, identity information, communication stage information, data range, data quantity, window-level verification information, cloud-level verification information, persistent closure credential, and closure status.
[0122] After the persistent closure credential is generated, the cloud writes the persistent closure status record to the persistent storage area. The persistent closure status record is written through the associated transaction after the persistent transaction of the corresponding data record is committed and the stored data reread verification is completed; after the persistent closure status record is successfully written, the closure status is set to closed.
[0123] When the cloud receives the synchronization responsibility window and corresponding data again, before writing the data, it generates a closed index of the responsibility window to be queried based on the identity information, communication stage information, data range, data quantity and window-level verification information of the synchronization responsibility window, and queries the persistent closed status table.
[0124] If a persistent closure record with a closed state is found, the cloud compares the identity information, communication stage information, data range, data quantity, and window-level verification information in that record with the newly received synchronization responsibility window. If the comparison matches, it indicates that the corresponding data range has been persistently closed. The cloud will not write the corresponding data record again, but will read the saved persistent closure certificate and resend the persistent closure certificate to the edge node.
[0125] If the data range corresponding to the responsibility window closure index is the same, but the window-level verification information is inconsistent, the cloud will not resend the original persistent closure certificate, and will generate the second type of responsibility window gap information according to the handling method of inconsistent cloud verification information and window-level verification information.
[0126] If the same responsibility window closure index is not found, but a corresponding closed persistent closure state record is found based on the identity information, communication stage information and data range, and the window-level verification information in the persistent closure state record is inconsistent with the synchronous responsibility window received again, the cloud will not resend the original persistent closure certificate, and will generate a second type of responsibility window gap information according to the processing method of inconsistent cloud verification information and window-level verification information.
[0127] This invention stores the persistent closure state and corresponding credentials of the synchronization responsibility window in the cloud. This allows the cloud to recover and resend the original persistent closure credential even when data has completed a persistent transaction commit and obtained a persistent closure credential, but the credential has not reached the edge node due to communication interruption or response loss. This approach helps avoid repeated writing and verification of the same data range and reduces the likelihood of edge nodes remaining in an unconfirmed synchronization position for extended periods due to credential transmission failures.
[0128] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.
Claims
1. A method for secure synchronization of photovoltaic power generation data based on edge-cloud collaboration, characterized in that, include: Edge nodes write photovoltaic power generation data to local logs with synchronization positions and maintain confirmed synchronization positions; Based on the confirmed synchronization location, select the data to be synchronized, construct a synchronization responsibility window that limits identity information, communication stage information, data range, data quantity and window-level verification information, and lock the data range; The synchronization responsibility window and the data to be synchronized are sent to the cloud. The cloud verifies the data to be synchronized and identifies missing and duplicate data. The cloud writes verified data through persistent transactions. After the transaction is committed, the stored data is reread according to the data range to verify the number and continuity of synchronization positions, and cloud verification information is generated based on the reread stored data. When the verification is successful and the cloud verification information is consistent with the window-level verification information, the termination log position of the data range is determined as the cloud-committed synchronization position and a persistent closure certificate is generated; otherwise, gap information is generated. When persistent closing credentials are matched with the synchronization responsibility window, the confirmed synchronization position is updated to the submitted synchronization position in the cloud; otherwise, the confirmed synchronization position remains unchanged. When the gap information is matched with the local synchronization responsibility window, the data is supplemented according to the gap information.
2. The method for secure synchronization of photovoltaic power generation data based on edge-cloud collaboration according to claim 1, characterized in that, The edge node writes photovoltaic power generation data into a local log with a synchronization location, including: the edge node collecting photovoltaic power generation status and power data of photovoltaic equipment to form photovoltaic power generation data; formatting and encapsulating the photovoltaic power generation data to generate data records containing data content, timestamps, and unique data stream identifiers; sequentially appending the data records to the local log; assigning a continuously increasing log position number to each data record in the local log, using the log position number as the corresponding synchronization position, and using the data stream identifier as an index to record the latest written log position number and the confirmed synchronization position, respectively.
3. The method for secure synchronization of photovoltaic power generation data based on edge-cloud collaboration according to claim 1, characterized in that, The process of constructing a synchronization responsibility window that defines identity information, communication stage information, data range, data quantity, and window-level verification information, and locking the data range, includes: extracting the data stream identifier and the photovoltaic device identifier from the edge node as identity information, and extracting the session connection identifier as communication stage information; using the log position numbers of the first and last data records in the data to be synchronized as the start log position and end log position, respectively, to constitute the data range, and counting the total number of data records within the data range as the data quantity; generating a record-level verification value based on the content of each data record and the log position number within the data range, and summarizing the record-level verification values to generate a window-level verification commitment value as the window-level verification information; and setting the attributes of all data records within the data range to read-only state to complete the locking of the data range.
4. The method for secure synchronization of photovoltaic power generation data based on edge-cloud collaboration according to claim 3, characterized in that, The cloud-based verification of data to be synchronized and identification of missing and duplicate data includes: the cloud allocating an independently bound memory sandbox as a receiving area based on the received identity information and communication stage information; verifying the content and source of the data to be synchronized based on digital signature and hash verification mechanisms, and removing data records that fail verification; verifying the log position number of the data records in the receiving area, and removing data records with duplicate log position numbers to complete duplicate data identification; comparing the consecutive numbers between the starting log position and the ending log position, and determining the numbers that do not match the corresponding log position number in the receiving area as missing data.
5. The method for secure synchronization of photovoltaic power generation data based on edge-cloud collaboration according to claim 1, characterized in that, The generation of the persistent closure credential includes: the cloud writes the verified and duplicate-free data records into the persistent storage area and establishes a persistent transaction for this write; after the persistent transaction is committed, the corresponding data records are reread from the persistent storage area according to the identity information and data range, the number of different log position numbers is counted, and the continuity of log position numbers from the start log position to the end log position is verified; based on the reread data records, the cloud window-level verification commitment value is recalculated and generated as cloud verification information; when the number of different log position numbers is equal to the number of data, the log position numbers are continuous, and the cloud verification information is consistent with the window-level verification information, the synchronization position corresponding to the end log position is determined as the cloud-committed synchronization position, and a credential file carrying the cloud digital signature is generated as the persistent closure credential.
6. The method for secure synchronization of photovoltaic power generation data based on edge-cloud collaboration according to claim 1, characterized in that, Otherwise, the generation of gap information includes: the cloud determines the missing data based on the verification results of the data to be synchronized and the reread results of the stored data after the transaction is committed; extracts the log position number corresponding to the missing data to generate a first type of responsibility window gap information; when the verification information in the cloud is inconsistent with the window-level verification information, extracts all log position numbers within the data range to generate a second type of responsibility window gap information; after the cloud performs digital signatures on the first type of responsibility window gap information and the second type of responsibility window gap information, it sends them to the edge nodes as the gap information.
7. The method for secure synchronization of photovoltaic power generation data based on edge-cloud collaboration according to claim 1, characterized in that, When the persistent closure credential is matched with the synchronization responsibility window, the confirmed synchronization position is updated to the cloud-submitted synchronization position. This includes: the edge node verifies the digital signature of the persistent closure credential; after successful verification, the identity information, communication stage information, data range, data quantity, and window-level verification information in the credential are compared with the locally locked synchronization responsibility window, and the cloud verification information in the credential is compared with the window-level verification information; if all the above information matches, the edge node updates the confirmed synchronization position of the corresponding data stream identifier to the cloud-submitted synchronization position in the persistent closure credential; the locking state of the data records between the start log position and the end log position is released, and the corresponding local cache space is released.
8. The method for secure synchronization of photovoltaic power generation data based on edge-cloud collaboration according to claim 1, characterized in that, When the gap information matches the local synchronization responsibility window, supplementary data is transmitted based on the gap information, including: when the gap information is a first type of responsibility window gap information, the edge node extracts the data record corresponding to the missing log position in the synchronization responsibility window; when the gap information is a second type of responsibility window gap information, it extracts all data records in the synchronization responsibility window; it uses the extracted data records to construct a compensation synchronization responsibility window associated with the synchronization responsibility window and sends it to the cloud; after the cloud writes the supplementary data, it performs a reread verification of the stored data according to the data range of the synchronization responsibility window, and generates a persistent closure certificate matching the synchronization responsibility window when the verification is successful.
