Photovoltaic power generation data cross-platform verification method and system

Abstract

This invention relates to the field of new energy data management and discloses a cross-platform verification method and system for photovoltaic power generation data. The method first collects instantaneous power generation data at the edge of the photovoltaic power station and combines this data with dynamic challenge codes from public physical beacons and device physical fingerprints to generate a metadata data package. A first platform server receives this data, calculates its hash value, and generates a first partial signature. Subsequently, at least one second platform server performs a physical correlation verification on the hash; if the verification passes, a second partial signature is generated. When the number of collected partial signatures reaches a preset threshold, they are aggregated to generate a federated signature. Finally, the data hash and federated signature are stored as verification records in a trusted state consensus ledger. This invention, by introducing physical randomness, federated signatures, and consensus ledger technology, achieves multi-party cross-verification, significantly improving the data's tamper-proof capability and credibility.

Description

Technical Field

[0001] This invention relates to the field of new energy data management technology, specifically to a cross-platform verification method and system for photovoltaic power generation data. Background Technology

[0002] With the rapid development of the photovoltaic industry, the power generation data generated by photovoltaic power plants has become a core basis for key operations such as grid dispatching, green certificate trading, subsidy settlement, and carbon footprint accounting. The authenticity, completeness, and tamper-proof nature of this data are directly related to the fairness and efficiency of the energy market.

[0003] In current technological practices, photovoltaic data is typically collected and stored on central servers by individual power plants or platform operators. Trust issues arise when this data needs to be transferred and used between different stakeholders (such as grid companies, regulatory agencies, and financial institutions). The data custodian is usually a single, centralized entity, an architecture that makes data records susceptible to malicious tampering. Whether by external attackers or internal personnel, historical data could be modified for illegal profit, and such tampering is often difficult to trace and verify effectively.

[0004] Therefore, in cross-entity collaborative scenarios, the data recipient cannot unilaterally ensure that the data it receives is original and tamper-free. This inherent distrust leads to significant costs for tedious manual reconciliation and auditing during data exchange, severely limiting the efficiency and application value of data elements. Existing data security measures, such as conventional digital signatures, while able to prove the data's origin to some extent, cannot establish a mechanism for multiple distrustful parties to cross-verify and jointly endorse the data, thus failing to fundamentally solve the trust problem of cross-platform data verification. Summary of the Invention

[0005] The present invention aims to solve the technical problems in the prior art where the authenticity of source data is difficult to guarantee when photovoltaic power generation data is transferred across platforms, it is susceptible to recording and replay attacks, and effective collaborative verification between platforms is difficult due to data privacy issues.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: The first aspect of this invention provides a cross-platform verification method for photovoltaic power generation data.

[0007] This method introduces a public physical beacon as a unified time reference for the entire network to generate unpredictable dynamic challenge codes. At the edge of the photovoltaic power station, while collecting instantaneous power generation data, a physical fingerprint characterizing the equipment's inherent electrical properties is extracted. This physical fingerprint, instantaneous power generation data, dynamic challenge codes, and data collection timestamps are then bound together to form a meta-data packet. This mechanism, by associating microscopic device data with macroscopic, tamper-proof, real-time physical events, ensures the liveness of the source data and effectively suppresses recording-and-replay attacks.

[0008] Subsequently, this method utilizes a federated signature mechanism based on distributed keys. The data holder (the first platform server) only needs to broadcast the cryptographic hash of its metadata, not the original data. Other participants (the second platform server), without accessing the original data, perform a physical correlation verification, using physically relevant reference data they possess (such as regional sunlight levels, grid load, etc.) to determine the legitimacy of the power generation event represented by the hash. Only after the verification passes do each party use its own private key fragments to generate a partial signature for the hash. Once a sufficient number of partial signatures are collected, they can be aggregated into an unrepudiable federated signature with cross-reinforcement from multiple physical entities.

[0009] Ultimately, the data hash and federated signature are stored as verification records in the trusted state consensus ledger, which solidifies the verification results and provides a public, transparent and efficient verification method for downstream data users.

[0010] Specifically, the cross-platform verification method for photovoltaic power generation data includes the following steps: S1. The dynamic challenge code generated in real time by the public physical beacon is obtained from the edge of the photovoltaic power station, and a meta data package is generated. The meta data package includes: instantaneous power generation data associated with the data acquisition timestamp, physical fingerprint, the dynamic challenge code, and the unique identifier of the device. S2. The first platform server receives the metadata data packet described in step S1. S3. The first platform server generates a first part of the signature based on the cryptographic hash of the meta data packet and the first private key fragment held by the first platform server; S4. After the physical correlation verification of the cryptographic hash is passed, at least one second platform server generates a second part of the signature based on the cryptographic hash and the second private key fragment held by the second platform server. S5. When the number of partial signatures collected by the cryptographic hash in step S3 reaches a preset threshold, a preset aggregation function is used to aggregate them into all partial signatures collected by the cryptographic hash to generate a federated signature; wherein, the preset threshold is an integer greater than 1. S6. The cryptographic hash described in step S3 and the federated signature described in step S5 are used as verification records and stored in the trusted state consensus ledger for subsequent verification of the instantaneous power generation data described in step S1.

[0011] In an optional embodiment, the physical fingerprint is a set of data characterizing the transient electrical characteristics of a photovoltaic power generation device, which may be selected from at least one of the following: high-frequency voltage or current waveform characteristics of the inverter, disturbance characteristics during maximum power point tracking, or inherent electronic noise characteristics of the device.

[0012] In an optional embodiment, the public physical beacon is a source that provides a macroscopic, unpredictable, and publicly verifiable real-time physical signal, which is derived from at least one selected from a power grid real-time frequency signal source or a satellite real-time clock signal source.

[0013] In an optional embodiment, the dynamic challenge code is a real-time code generated within the same preset time window as the data collection timestamp, used to ensure that the generation of the metadata data has a non-replayable proof of liveness.

[0014] In an optional embodiment, the first private key fragment and the second private key fragment are generated by multiple platform servers, including the first platform server and the second platform server, jointly executing a distributed key generation protocol. This protocol ensures that no single platform server holds the complete federated master private key, but only holds private key fragments that cannot be independently signed.

[0015] In an optional embodiment, the physical correlation verification is specifically performed by: firstly, the second platform server, based on its internal reference data, generates a reference state interval describing the expected power generation environment in the physical region where the first platform server is located. The reference state interval is generated by first calculating a baseline state value, and then determining the upper and lower limits of the reference state interval in conjunction with dynamic tolerance. Its mathematical expression is as follows: ; in, The reference state interval, The reference state value is calculated based on the internal reference data. This refers to the dynamic tolerance.

[0016] Then, the second platform server receives a quantized power generation event state descriptor associated with the cryptographic hash from the first platform server. Finally, it determines whether the value corresponding to the power generation event state descriptor falls within the reference state range. If the determination result is yes, the physical correlation verification is considered to have passed.

[0017] In an optional embodiment, the subsequent step of verifying the instantaneous power generation data specifically includes: obtaining the verification record from the trusted state consensus ledger; after obtaining the verification record, generating a recalculated cryptographic hash by recalculating the metadata to be verified, and comparing the recalculated cryptographic hash with the cryptographic hash contained in the verification record to generate a hash comparison result; when the hash comparison result is consistent, using a federated public key to verify the validity of the federated signature contained in the verification record.

[0018] In an optional embodiment, the preset aggregation function is a function based on cryptographic group addition, used to synthesize multiple collected partial signatures into a single federated signature. The specific calculation method of the aggregation function is expressed as follows: ; in, For the federal signature, For the collected number Each part of the signature, The number of partial signatures is not less than the preset threshold.

[0019] In an optional embodiment, the trusted state consensus ledger is a distributed ledger.

[0020] In an optional embodiment, the physical fingerprint has a one-to-one correspondence with the device's unique identifier, used to uniquely identify the photovoltaic power generation device.

[0021] In an optional embodiment, the physical fingerprint extraction method includes: acquiring voltage or current waveforms on the inverter output side using a high-frequency sensor, performing a fast Fourier transform on the acquired waveforms, extracting the amplitude and phase angle of specific higher harmonics, and combining them into a feature vector.

[0022] In an optional embodiment, the power generation event status descriptor is a level identifier obtained after performing hierarchical quantization processing on the instantaneous power generation data.

[0023] In an optional embodiment, the dynamic tolerance δ_dyn is calculated based on the historical statistical variance of the internal reference data or a preset confidence level.

[0024] In an optional embodiment, the preset threshold is determined based on the total number of platform servers participating in the distributed key generation protocol and a preset security level.

[0025] In an optional embodiment, the verification record is written into a new block of the distributed ledger via a consensus protocol.

[0026] A second aspect of the present invention provides a cross-platform verification system for photovoltaic power generation data, the system being configured to perform the method described in any of the preceding claims.

[0027] Specifically, the system includes: A receiving module is used to receive metadata data from the edge of a photovoltaic power station. The metadata data contains a physical fingerprint associated with instantaneous power generation data, generated based on a dynamic challenge code generated in real time by a public physical beacon. A first signature module is located at the first platform server and is used to generate a first partial signature based on the cryptographic hash of the metadata data and a first private key fragment held by the first platform server. The second signature module, located at at least one second platform server, is used to generate a second signature based on the cryptographic hash and a second private key fragment held by the second platform server after the physical correlation verification of the cryptographic hash has passed. An aggregation module is used to aggregate the first part of the signature and the second part of the signature into a federated signature when the number of partial signatures for the cryptographic hash reaches a preset threshold. And a storage module for storing the cryptographic hash and the federated signature as verification records in a trusted state consensus ledger.

[0028] This invention provides a cross-platform verification method and system for photovoltaic power generation data, which has the following beneficial effects: This invention establishes a strong correlation between the data generation time and the real-time state of the macroscopic physical world by binding metadata containing physical fingerprints with dynamic challenge codes from public physical beacons. This provides proof of the source data's liveness, effectively suppressing record-replay attacks and enhancing the credibility of the source data. By employing a federated signature mechanism, participating platforms only need to exchange cryptographic hashes without sensitive information to initiate and participate in verification. Physical correlation verification indirectly determines the rationality of power generation events, avoiding direct exposure of the original data. This achieves effective collaborative verification while ensuring the data privacy and security of each platform. By combining device-level microscopic physical fingerprints with cross-platform macroscopic physical correlation verification, a multi-dimensional, multi-layered verification system from microscopic to macroscopic is constructed. This makes it difficult for any single-dimensional forgery to pass cross-verification, significantly increasing the difficulty and cost of data forgery, thereby improving the overall accuracy and reliability of cross-platform data verification. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the system architecture of the present invention; Figure 2 This is a flowchart illustrating the cross-platform verification method for photovoltaic power generation data of the present invention. Figure 3 This is a schematic diagram of the distributed key generation process of the present invention; Figure 4 This is a schematic diagram illustrating the process of generating metadata at the edge of a photovoltaic power station according to the present invention. Figure 5 This is a schematic diagram of the module structure of the verification system of the present invention. Detailed Implementation

[0030] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application. The step numbers in the following embodiments are set only for ease of explanation, and there is no limitation on the order between the steps. The execution order of each step in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0031] In the description of this application, unless otherwise expressly defined, terms such as "setup," "installation," and "connection" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this application in conjunction with the specific content of the technical solution.

[0032] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application. The step numbers in the following embodiments are set only for ease of explanation, and there is no limitation on the order between the steps. The execution order of each step in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0033] In the description of this application, unless otherwise expressly defined, terms such as "setup," "installation," and "connection" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this application in conjunction with the specific content of the technical solution.

[0034] To address the technical challenge of reducing the accuracy of battery management system performance evaluation, fault diagnosis, and lifespan prediction, the battery operation data of electrochemical energy storage systems is susceptible to noise, drift, and abrupt changes caused by environmental temperature, load fluctuations, and charge / discharge frequency under actual operating conditions.

[0035] See attached document Figure 1This is a schematic diagram of the architecture of a cross-platform verification system for photovoltaic power generation data according to an embodiment of the present invention. The system serves as the execution environment for a cross-platform verification method for photovoltaic power generation data, which verifies photovoltaic power generation data through multiple collaboratively operating functional entities.

[0036] The system architecture provided in this embodiment of the invention includes: a photovoltaic power station edge terminal 10, at least two platform servers (shown as a first platform server 20a and a second platform server 20b for clarity), a public physical beacon source 30, a trusted state consensus ledger 40, and a data user 50.

[0037] Public physical beacon source 30 is configured to acquire unpredictable real-time state values ​​from macroscopic physical phenomena and generate dynamic challenge codes based on these real-time state values. This dynamic challenge code It is periodically broadcast to the edge of one or more photovoltaic power plants 10.

[0038] The photovoltaic power station edge terminal 10, deployed at the physical site where the data is generated, is configured to perform step S1 of the method of the present invention.

[0039] Specifically, the edge terminal 10 of the photovoltaic power station receives a dynamic challenge code broadcast by the public physical beacon source 30. While collecting instantaneous power generation data from photovoltaic power generation equipment, the system simultaneously extracts the equipment's physical fingerprint. Subsequently, it generates a structured metadata package. The structure of this metadata packet can be represented as follows: ; in, Metadata packets; This is instantaneous power generation data; Physical fingerprint; For data collection timestamps; It is a dynamic challenge code; This is a unique identifier for photovoltaic power generation equipment. After generation, the edge device 10 of the photovoltaic power station will use this metadata data. Send to its home platform server 20a.

[0040] The first platform server 20a and the second platform server 20b are computing entities operated by different data holders. The first platform server 20a receives the metadata data. Then, step S3 of the method of the present invention is performed, namely, calculating the cryptographic hash of the meta-data packet. and use the first private key fragment it holds to hash the hash Perform the signing process to generate the first part of the signature.

[0041] Subsequently, the first platform server 20a will use cryptographic hashes. The first part of the signature is broadcast to one or more second platform servers 20b. Upon receiving this information, the second platform server 20b executes step S4 of the method of the present invention, that is, first performs a cryptographic hash... The power generation event it represents undergoes a physical correlation verification. If the verification passes, the same cryptographic hash is generated using the second private key fragment it holds. A signature is generated to form a second part of the signature. When the number of collected partial signatures reaches a preset threshold, a complete federated signature is generated.

[0042] The trusted state consensus ledger 40 is used to execute step S6 of the method of the present invention. It is a distributed data storage facility accessible to servers on all platforms, configured to receive and persistently store verification records composed of cryptographic hashes and federated signatures. Due to the characteristics of the ledger, the verification records possess the properties of immutability and traceability.

[0043] Data user 50 is a downstream application or organization that needs to use verified photovoltaic power generation data. Data user 50 obtains the original metadata data from the first platform server 20a and the corresponding verification record from the trusted state consensus ledger 40. By performing local cryptographic operations, data user 50 can complete the final verification of data trustworthiness.

[0044] See attached document Figure 2 , Figure 2 This is a flowchart illustrating a cross-platform verification method for photovoltaic power generation data according to an embodiment of the present invention. The cross-platform verification method for photovoltaic power generation data provided by the present invention may include the following steps: Step S1: The photovoltaic power station edge terminal 10 obtains the dynamic challenge code generated in real time by the public physical beacon source 30 and generates a meta data packet.

[0045] Specifically, the edge terminal 10 of the photovoltaic power station receives the dynamic challenge code. Then, the challenge code is compared with the instantaneous power generation data collected within the same preset time window. Extracted physical fingerprints The corresponding data collection timestamp and unique device identifier Combine them to generate a structured meta-data packet. .

[0046] Step S2: The first platform server 20a receives the metadata from step S1. The receiving process involves transmitting the generated metadata data via the photovoltaic power station edge terminal 10. It is uploaded to the first platform server 20a to which it belongs via a communication network.

[0047] Step S3: The first platform server 20a generates a first partial signature based on the cryptographic hash of the metadata packet and the first private key fragment held by the first platform server. Specifically, the first platform server 20a first processes the received complete metadata packet... The cryptographic hash is calculated by applying a pre-defined hash function. : ; in, For cryptographic hashing, This is the preset hash function.

[0048] Subsequently, the first platform server 20a uses the first private key fragment it holds locally. This hash value Perform signature calculations to generate the first part of the signature. .

[0049] Step S4: After the physical correlation verification of the cryptographic hash is passed, at least one second platform server 20b generates a second part of the signature based on the cryptographic hash and the second private key fragment held by the second platform server. Specifically, the first platform server 20a uses the cryptographic hash... The broadcast is sent to the second platform server 20b. The second platform server 20b receives the broadcast. Then, a physical association verification is performed first. If the verification passes, the second private key fragment held locally is used. For the same hash value Perform signature calculations to generate the second part of the signature. .

[0050] Step S5: When the number of partial signatures collected from the cryptographic hash in step S3 reaches a preset threshold, a preset aggregation function is used to aggregate them into all partial signatures collected from the cryptographic hash to generate a federated signature. This process involves combining multiple partial signatures (e.g., those generated by servers on different platforms) that have been collected. Aggregation is performed. This aggregation process is completed by a predefined aggregation function, whose mathematical expression is: ; in, The federated signature generated after aggregation For the collected first Each part of the signature, The total number of partial signatures collected, and The value is not less than a preset threshold. The preset threshold is an integer greater than 1.

[0051] Step S6: The cryptographic hash from step S3 and the federated signature from step S5 are used as verification records and stored in the trusted state consensus ledger 40. This verification record, namely... The data pairs are sent to the trusted state consensus ledger 40 for recording and solidification, so as to provide undeniable verification of the instantaneous power generation data in step S1.

[0052] Before the method of this invention is executed, an initialization step is required. The initialization step is used to establish the cryptographic foundation required for subsequent signature verification, and to ensure the security and distributed nature of the verification process.

[0053] See attached document Figure 3 , Figure 3 This is a schematic diagram of a distributed key generation process according to an embodiment of the present invention. In one embodiment, the initialization step is jointly performed by multiple platform servers that plan to participate in data verification, such as a first platform server 20a, a second platform server 20b, and other platform servers not shown. These platform servers jointly execute a distributed key generation protocol.

[0054] The execution of a distributed key generation protocol aims to generate a key pair for threshold signature schemes among multiple participants without requiring a trusted third party. Upon completion of the protocol, the following two types of cryptographic materials are generated: First, generate a unified federal public key across the entire network. This federal public key It is public and will be distributed to all participating platform servers and subsequent data users. This federal public key... Used to verify the validity of the final aggregated federated signature.

[0055] Secondly, a unique federated private key fragment is generated for each participating platform server. For example, the first platform server 20a obtains and secretly holds the first private key fragment. The second platform server 20b obtains and secretly holds the second private key fragment. This protocol ensures that each platform server holds only its own fragment of the private key, and that the complete federated master private key is never aggregated or reconstructed at any single entity during its generation, storage, or use.

[0056] The process of executing the distributed key generation protocol also includes setting a preset threshold. The threshold `f(x)` is an integer greater than 1 that defines the minimum number of partial signatures required to generate a valid federated signature. `f(x)` is a condition that, if and only if `f(x)` is collected from at least `f(x)`, then `f(x)` is a condition that, if and only if ... Only when multiple servers on different platforms sign the valid parts of the same cryptographic hash can they be successfully aggregated into a single hash that can be verified using a federated public key. Verified federal signature. Any less than None of the partial signature combinations can generate a valid federal signature.

[0057] See attached document Figure 4 , Figure 4 This is a schematic diagram illustrating the process of generating metadata at the edge of a photovoltaic power station according to an embodiment of the present invention. This process details the execution of step S1 of the method of the present invention, namely, at the source of data generation, by introducing the randomness of the external physical world and the inherent physical characteristics of the device, a reliable data foundation is built for subsequent cross-platform verification.

[0058] In one embodiment, the photovoltaic power station edge device 10 first obtains a dynamic challenge code from a public physical beacon source 30. The Public Physical Beacon Source 30 is an independent, publicly accessible signal source that continuously extracts unpredictable real-time signals from the macroscopic physical world.

[0059] For example, a public physical beacon source 30 can be connected to the power grid and monitor the grid's real-time operating frequency with high precision. Because the power grid frequency exhibits small, non-periodic random fluctuations around its nominal value (e.g., 50 Hz), at any given time... High-precision frequency readings It is unpredictable. The public physical beacon source 30 can provide this reading. Processing is performed, such as hashing, to generate a dynamic challenge code for that moment. It also broadcasts to the edge of the photovoltaic power station 10 in the network.

[0060] In another embodiment, the public physical beacon source 30 can extract signals from satellite real-time clock signals (e.g., GPS signals). These signals exhibit minute, unpredictable jitter due to signal propagation and the physical limitations of the clock itself; this jitter characteristic can also be processed to generate dynamic challenge codes. .

[0061] The photovoltaic power station edge device 10 receives the dynamic challenge code Simultaneously, it collects instantaneous power generation data internally. To ensure data vitality—that is, to prove that the data was generated "freshly" at a specific point in time, rather than a replay of historical data—the edge device 10 of the photovoltaic power station performs a synchronization check. Specifically, it records its own data collection timestamps. With the received dynamic challenge code The generated timestamp is compared with the bound timestamp. The dynamic challenge code is only valid if the two timestamps are within the same preset time window (e.g., the time difference is less than 1 second). Only then is it considered valid and used in subsequent steps.

[0062] Collecting instantaneous power generation data At the same time, the edge terminal 10 of the photovoltaic power station also simultaneously extracts the physical fingerprint of the power generation equipment (e.g., photovoltaic inverter). A physical fingerprint is a set of data used to characterize the transient electrical characteristics of a device unique to it and caused by manufacturing tolerances. In one embodiment, the physical fingerprint is extracted by: acquiring the waveform of the inverter's AC output side using a high-frequency current or voltage sensor; performing a Fast Fourier Transform (FFT) on the acquired digital waveform; and extracting the amplitude and phase angle of specific higher harmonics (e.g., the 3rd, 5th, and 7th harmonics). These values ​​are then combined into a feature vector, which serves as the physical fingerprint of the device. .

[0063] In another embodiment, the physical fingerprint is extracted by monitoring and recording minute, periodic disturbances in the DC-side voltage or current caused by the inverter's internal "disturbance observation" mechanism when executing the Maximum Power Point Tracking (MPPT) algorithm. The specific waveform, frequency, and amplitude of this disturbance are related to the device's control parameters and hardware characteristics, and therefore can be quantified as a unique physical fingerprint. .

[0064] Finally, the edge device 10 of the photovoltaic power station encapsulates the collected and extracted data items to generate a structured metadata data package. This metadata packet Includes: instantaneous power generation data Physical fingerprints Data collection timestamp Dynamic challenge codes that pass activity verification and the unique identifier of the equipment. (e.g., device serial number). This metadata packet As a whole, it will be sent to the first platform server 20a to initiate the subsequent cross-platform verification process.

[0065] This process involves the first platform server 20a receiving metadata from the photovoltaic power station edge terminal 10. After startup, through the collaborative work between multiple platform servers, the joint endorsement of data credibility is completed without disclosing the original sensitive data.

[0066] The process begins with step S3 of the method of the present invention. The first platform server 20a receives the metadata data packet. Then, a pre-defined, collision-resistant cryptographic hash function (e.g., SHA-256) is first applied to the metadata packet. The complete content is processed to generate a fixed-length cryptographic hash. ; ; in, For cryptographic hashing, This represents a hash function. The hash value... Can be used as meta data packet The unique digital digest. Subsequently, the first platform server 20a invokes the first private key fragment it obtained during the initialization phase. Regarding this cryptographic hash Perform signature calculations to generate the first part of the signature. .

[0067] Next, the first platform server 20a sends a verification request to one or more second platform servers 20b. This request does not contain the original metadata. Instead, it includes cryptographic hashes. and a quantized power generation event state descriptor associated with that hash. State descriptor Instantaneous power generation data in the metadata A non-sensitive, hierarchical representation, for example, dividing the inverter's rated power into 10 levels, state descriptor This refers to the level number to which the instantaneous power generation data belongs.

[0068] Upon receiving the verification request, the second platform server 20b executes step S4 of the method of this invention, the core of which is physical correlation verification. This verification, without accessing the original power generation data, utilizes internal reference data held by the second platform server 20b to determine the physical rationality of the power generation event. Specific verification methods include: First, the second platform server 20b calculates a reference state interval describing the expected power generation environment of the physical area where the first platform server 20a is located, based on its internal reference data (e.g., real-time meteorological data of its geographical area, historical power generation data of other photovoltaic power plants in the area, or grid load forecasting models). The calculation method for this interval is as follows: ; in, This is a baseline state value calculated based on internal reference data. For example, meteorological data such as light intensity and ambient temperature can be used to calculate the value at a specific timestamp using a photovoltaic power generation physical model. The theoretical output power level of a standard photovoltaic device at any given time. This is a dynamic tolerance used to cover uncertainties such as model errors and sudden weather changes; its value can be determined based on the statistical variance of historical data or a preset confidence level. Subsequently, the second platform server 20b determines the power generation event status descriptor provided by the first platform server 20a. Does the corresponding value fall within its calculated reference state range? If the result is yes, then the physical correlation check is considered passed.

[0069] After the physical association verification is passed, the second platform server 20b uses the second private key fragment it holds locally. For the same cryptographic hash received Perform signature calculations to generate the second part of the signature. And return it to the requester.

[0070] When collected, targeting the same cryptographic hash The number of partial signatures reached a preset threshold When the time comes, step S5 of the method of the present invention is initiated. This step uses a preset aggregation function to aggregate all collected partial signatures (e.g., (etc.) are combined into a single federal signature. .

[0071] In one embodiment, the aggregation function is a function based on cryptographic group addition, and its specific calculation method can be expressed as follows: ; in, For the final generated federal signature, For the collected first A valid partial signature, This represents the total number of partial signatures collected. The addition here... It is a point addition operation defined on a specific group of elliptic curves. The generated federated signature. It has a characteristic that it can use the federated public key generated during the initialization phase. Verification is performed to prove the hash. At least Joint confirmation from individual participating parties.

[0072] In step S5, the federated signatures were successfully aggregated and generated. Then, step S6 of the method of the present invention is performed. Specifically, the cryptographic hash is... Its corresponding federal signature The data is combined to form a structured verification record. This verification record, along with other ancillary information (e.g., the timestamp of the aggregation completion, the list of identifiers of participating signing platforms, etc.), is submitted as a transaction to the trusted state consensus ledger 40.

[0073] In one embodiment, the trusted state consensus ledger 40 is a distributed ledger, such as a consortium blockchain built on blockchain technology. Platform servers 20a, 20b, etc., act as nodes in this ledger network, executing the consensus protocol to write verification records into a new block and append it to the ledger chain. Due to the immutable, transparent, and traceable characteristics of distributed ledgers, once a verification record is written, it is permanently fixed, providing objective and undeniable evidence for subsequent verification.

[0074] The technical solution of this invention also includes a step of subsequent verification of the instantaneous power generation data. This step is performed by the data user 50 to confirm the authenticity and completeness of the photovoltaic power generation data it has acquired. The specific verification process is as follows: First, the data user 50 obtains the raw metadata data to be verified from the data provider (e.g., the first platform server 20a). .

[0075] Meanwhile, the data user 50 uses the index information of the meta-data packet (e.g., its cryptographic hash) (or related transaction ID), query and retrieve the corresponding on-chain verification record from the trusted state consensus ledger 40. .

[0076] After obtaining the above two data items, the data user 50 performs a verification operation locally. First, it uses the same hash function as the first platform server 20a in step S3 to process the obtained metadata data. Recalculate to generate a recalculated cryptographic hash. Then, the recalculated hash Hash obtained from the ledger Perform precise comparison.

[0077] A hash match occurs if and only if the hash comparison results are consistent (i.e. This indicates the metadata data held by data user 50. The content has not been tampered with in any way since the original hash was generated. Under this condition, data user 50 continues with the second step of verification.

[0078] The second step is to verify the validity of the federal signature. Data user 50 uses a pre-obtained, publicly available federal public key. For the federal signature in the verification record The validity of the signature is cryptographically verified. This verification confirms whether the signature was indeed created by a platform provider holding at least a preset threshold of private key fragments, targeting the hash. They were generated together.

[0079] If the validity verification of the federal signature passes, then data user 50 will finally confirm that it holds the metadata data. Instantaneous power generation data contained therein It is authentic, complete, and its validity has been cross-endorsed by multiple platforms. If the hash comparison is inconsistent or the federated signature verification fails, the instantaneous power generation data is deemed invalid or untrustworthy.

[0080] The steps described above are explained in detail below. In step S1, the photovoltaic power station edge refers to a terminal device with computing and communication capabilities deployed at the photovoltaic power station site, such as an industrial control computer or a data acquisition device. A public physical beacon is a source that provides a macroscopic, unpredictable, and publicly verifiable real-time physical signal. In a specific example, this public physical beacon can be a high-precision power grid frequency monitoring device that collects the operating frequency of the power grid in real time. Due to random variations in power grid load, the frequency exhibits small, non-periodic random fluctuations around the nominal value (e.g., 50Hz), which are unpredictable at specific moments. The device uses the collected real-time frequency value as a dynamic challenge code and periodically broadcasts it to the photovoltaic power station edge via wired or wireless networks. In another example, the public physical beacon can also be a real-time clock signal with nanosecond-level jitter characteristics received from a satellite navigation system (e.g., GPS). The dynamic challenge code and the data acquisition timestamp are generated within the same preset time window to ensure that the generation of the metadata data has a non-replayable proof of activity. For example, when the photovoltaic power station edge receives the dynamic challenge code C... t Then, the device's own time t is recorded. If the difference between t and the generation time of the dynamic challenge code is less than 1 second, the challenge code is considered valid. The physical fingerprint is a set of data characterizing the transient electrical characteristics of the photovoltaic power generation equipment. For example, the voltage or current waveform at the inverter output is collected by a high-frequency sensor, and the amplitudes of its 3rd and 5th harmonics are extracted as feature vectors. The unique identifier of the device can be the inverter's factory serial number. The photovoltaic power station edge packages this data into a structured metadata packet. This metadata packet encapsulates all the context information of the data, providing an unforgeable data foundation for subsequent verification. In step S2, the first platform server receives this metadata packet through the communication network. In step S3, the first platform server first uses a preset hash function (such as SHA-256) to calculate the hash value H of the metadata packet. i =Hash(M iThen, the first platform server calls the first private key fragment sk, which it obtained during the initialization phase through a distributed key generation protocol. a , for H i Perform signature calculations to generate the first part of the signature σ. a In step S4, the first platform server will send H i And a quantized power generation event state descriptor D associated with that hash. q (For example, dividing power generation capacity into 10 levels, D) q The level number is sent to the second platform server. The second platform server first performs a physical correlation check. For example, based on its own collected local light intensity, ambient temperature and other meteorological data, it calculates the theoretical output power level at time t through the photovoltaic power generation physical model, forming a reference state interval CI. ref If D q If the value falls within this range, the verification passes. Subsequently, the second platform server uses the second private key fragment sk it holds. b Sign Hi to generate the second part of the signature σ. b And return. In step S5, the preset aggregation module collects data for H. i When the number of partial signatures reaches a preset threshold k (e.g., k=3), an aggregation function is called, such as performing point addition on an elliptic curve group: FS agg =σ a +σ b +..., generate federated signature FS agg In step S6, {H} i , FSagg} is submitted as a verification record to the trusted state consensus ledger. For example, in a consortium blockchain built on Hyperledger Fabric, the data is written into a block after consensus by multiple platform nodes, thus realizing the solidification and notarization of data.

[0081] This method ensures the freshness and authenticity of source data by binding microscopic device physical fingerprints to macroscopic random events in the physical world. Through hash exchange and physical correlation verification, collaborative verification is achieved while protecting the data privacy of each platform. Federated signature technology ensures that no single platform can independently endorse data; multiple parties must participate and reach a threshold to generate a valid signature, achieving true multi-party trust. Finally, the verification results are stored in an immutable distributed ledger, providing public, transparent, and non-repudiable credentials for subsequent data auditing and use.

[0082] To achieve the aforementioned method, this invention also provides a cross-platform verification system for photovoltaic power generation data. (See attached document.) Figure 1 and attached Figure 5 , attached Figure 5This is a schematic diagram of the module structure of a verification system according to an embodiment of the present invention. The system is configured to perform the cross-platform verification method for photovoltaic power generation data described in any of the foregoing embodiments.

[0083] In one specific embodiment, the system includes: a receiving module, a first signature module, a second signature module, an aggregation module, and a storage module.

[0084] A receiving module is deployed on the first platform server 20a. The function of this module is to receive metadata generated by one or more photovoltaic power plant edge terminals 10 via a communication network. The receiving module receives the metadata data packet. Then, it is submitted to the first signature module for processing.

[0085] The first signature module is also deployed on the first platform server 20a. This module is connected to the receiving module and is used to execute step S3 of the method of the present invention. Specifically, the first signature module, upon receiving the metadata data packet,... Then, a preset hash function is applied to it to generate a cryptographic hash. And call the first private key fragment stored in the first platform server 20a. For this hash Perform signature calculations to generate the first part of the signature. After signing, the module will perform a cryptographic hash. and associated power generation event status descriptors Send to one or more second platform servers 20b.

[0086] The second signature module is deployed on each participating second platform server 20b. The function of this module is to execute step S4 of the method of the present invention. Specifically, the second signature module receives the cryptographic hash from the first signature module. and state descriptor Next, a physical association verification is performed. If this verification passes, the module invokes the second private key fragment stored on its server. For the same hash Perform signature calculations to generate the second part of the signature. And return that part of the signature.

[0087] An aggregation module can be deployed on the first platform server 20a. This module communicates with the first signature module and the second signature module and is used to execute step S5 of the method of the present invention. The aggregation module is responsible for collecting the signatures generated by the first signature module. and the signature returned by one or more second signature modules Partial signatures, etc. This module continuously monitors collected signatures for the same hash. The number of partial signatures, when that number reaches a preset threshold. Upon receiving the message, the module immediately invokes a pre-defined aggregation function to aggregate all valid partial signatures into a final federated signature. .

[0088] The storage module can also be deployed on the first platform server 20a. This module is connected to the aggregation module and has an interface for communicating with the trusted state consensus ledger 40. Its function is to execute step S6 of the method of the present invention. The aggregation module generates a federated signature. Then, the storage module obtains the federated signature and its corresponding cryptographic hash. They are then constructed into a verification record and submitted as a transaction to the trusted state consensus ledger 40 for on-chain storage.

[0089] During system operation, the aforementioned modules work together to ensure that photovoltaic power generation data, starting from its source, undergoes a collaborative verification process involving multiple parties and protecting privacy, ultimately solidifying its credibility proof onto the distributed ledger, thereby fully realizing the technical solution of this invention.

[0090] A third objective of this application is to provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the aforementioned cross-platform verification method for photovoltaic power generation data. The device also includes a communication interface and a bus.

[0091] The aforementioned method for cross-platform verification of photovoltaic power generation data includes: S1. The dynamic challenge code generated in real time by the public physical beacon is obtained from the edge of the photovoltaic power station, and a meta data package is generated. The meta data package includes: instantaneous power generation data associated with the data acquisition timestamp, physical fingerprint, dynamic challenge code and unique device identifier; S2. The first platform server receives the metadata data from step S1. S3. The first platform server generates a first part of the signature based on the cryptographic hash of the meta data packet and the first private key fragment held by the first platform server; S4. After the physical correlation verification of the cryptographic hash is passed, at least one second platform server generates a second part of the signature based on the cryptographic hash and the second private key fragment held by the second platform server. S5. When the number of partial signatures collected by the cryptographic hash in step S3 reaches a preset threshold, a preset aggregation function is used to aggregate them into all partial signatures collected by the cryptographic hash to generate a federated signature; wherein, the preset threshold is an integer greater than 1. S6. The cryptographic hash in step S3 and the federated signature in step S5 are used as verification records and stored in the trusted state consensus ledger for subsequent verification of the instantaneous power generation data in step S1.

[0092] The fourth objective of this application is to provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned cross-platform verification method for photovoltaic power generation data.

[0093] The aforementioned method for cross-platform verification of photovoltaic power generation data includes: S1. The dynamic challenge code generated in real time by the public physical beacon is obtained from the edge of the photovoltaic power station, and a meta data package is generated. The meta data package includes: instantaneous power generation data associated with the data acquisition timestamp, physical fingerprint, dynamic challenge code and unique device identifier; S2. The first platform server receives the metadata data from step S1. S3. The first platform server generates a first part of the signature based on the cryptographic hash of the meta data packet and the first private key fragment held by the first platform server; S4. After the physical correlation verification of the cryptographic hash is passed, at least one second platform server generates a second part of the signature based on the cryptographic hash and the second private key fragment held by the second platform server. S5. When the number of partial signatures collected by the cryptographic hash in step S3 reaches a preset threshold, a preset aggregation function is used to aggregate them into all partial signatures collected by the cryptographic hash to generate a federated signature; wherein, the preset threshold is an integer greater than 1. S6. The cryptographic hash in step S3 and the federated signature in step S5 are used as verification records and stored in the trusted state consensus ledger for subsequent verification of the instantaneous power generation data in step S1.

[0094] The fifth objective of this application is to provide a computer program product, which includes computer instructions that instruct a computer to execute the above-described cross-platform verification method for photovoltaic power generation data.

[0095] The aforementioned method for cross-platform verification of photovoltaic power generation data includes: S1. The dynamic challenge code generated in real time by the public physical beacon is obtained from the edge of the photovoltaic power station, and a meta data package is generated. The meta data package includes: instantaneous power generation data associated with the data acquisition timestamp, physical fingerprint, dynamic challenge code and unique device identifier; S2. The first platform server receives the metadata data from step S1. S3. The first platform server generates a first part of the signature based on the cryptographic hash of the meta data packet and the first private key fragment held by the first platform server; S4. After the physical correlation verification of the cryptographic hash is passed, at least one second platform server generates a second part of the signature based on the cryptographic hash and the second private key fragment held by the second platform server. S5. When the number of partial signatures collected by the cryptographic hash in step S3 reaches a preset threshold, a preset aggregation function is used to aggregate them into all partial signatures collected by the cryptographic hash to generate a federated signature; wherein, the preset threshold is an integer greater than 1. S6. The cryptographic hash in step S3 and the federated signature in step S5 are used as verification records and stored in the trusted state consensus ledger for subsequent verification of the instantaneous power generation data in step S1.

[0096] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0097] These computer program instructions can also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0098] This application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, readable storage media, optical storage, etc.) containing computer-usable program code.

[0099] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0100] Obviously, the described embodiments are only some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort should fall within the scope of protection of this application.

[0101] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and not to limit them. Although this application has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation methods of this application. Any modifications or equivalent substitutions that do not depart from the spirit and scope of this application should be covered within the protection scope of this application.

Claims

1. A method for cross-platform verification of photovoltaic power generation data, characterized in that, include: S1. The dynamic challenge code generated in real time by the public physical beacon is obtained from the edge of the photovoltaic power station, and a meta data package is generated. The meta data package includes: instantaneous power generation data associated with the data acquisition timestamp, physical fingerprint, the dynamic challenge code, and the unique identifier of the device. S2. The metadata is received by the first platform server. S3. The first platform server generates a first part of the signature based on the cryptographic hash of the metadata and the first private key fragment held by the first platform server; S4. After the physical correlation verification of the cryptographic hash is passed, at least one second platform server generates a second part of the signature based on the cryptographic hash and the second private key fragment held by the second platform server. S5. When the number of partial signatures collected for the cryptographic hash reaches a preset threshold, a preset aggregation function is used to aggregate them into all partial signatures collected for the cryptographic hash to generate a federated signature. S6. The cryptographic hash and the federated signature are stored as verification records in the trusted state consensus ledger for subsequent verification of the instantaneous power generation data.

2. The method for cross-platform verification of photovoltaic power generation data according to claim 1, characterized in that, In S2, the physical fingerprint is a set of data characterizing the transient electrical characteristics of the photovoltaic power generation equipment. The data is selected from at least one of the following: high-frequency voltage or current waveform characteristics of the inverter, disturbance characteristics during the maximum power point tracking process, or inherent electronic noise characteristics of the equipment. The physical fingerprint extraction method includes: acquiring voltage or current waveforms on the output side of the inverter through a high-frequency sensor, performing a fast Fourier transform on the acquired waveform, extracting the amplitude and phase angle of specific higher harmonics, and combining them into a feature vector.

3. The method for cross-platform verification of photovoltaic power generation data according to claim 1, characterized in that, In S1, the public physical beacon is a macroscopic, unpredictable, and publicly verifiable real-time physical signal, which is derived from at least one source selected from a power grid real-time frequency signal source or a satellite real-time clock signal source.

4. The method for cross-platform verification of photovoltaic power generation data according to claim 1, characterized in that, In S1, the dynamic challenge code and the data collection timestamp are generated in real time within the same preset time window to ensure that the generation of the meta data packet has a non-replayable proof of liveness.

5. The method for cross-platform verification of photovoltaic power generation data according to claim 1, characterized in that, The first private key fragment and the second private key fragment are generated by multiple platform servers, including the first platform server and the second platform server, jointly executing a distributed key generation protocol.

6. The method for cross-platform verification of photovoltaic power generation data according to claim 1, characterized in that, The specific execution methods for the physical correlation verification described in S4 include: The second platform server, based on internal reference data, generates a reference state range describing the expected power generation environment in the physical area where the first platform server is located. The reference state range is generated by first calculating a baseline state value, and then determining the upper and lower limits of the reference state range using dynamic tolerances. Its mathematical expression is as follows: ； in, The reference state interval, The reference state value is calculated based on the internal reference data. The dynamic tolerance; The second platform server receives a quantized power generation event status descriptor associated with the cryptographic hash from the first platform server; Determine whether the value corresponding to the power generation event state descriptor falls within the reference state range. If the result is yes, then the physical correlation verification is considered to have passed.

7. The method for cross-platform verification of photovoltaic power generation data according to claim 1, characterized in that, In S6, the subsequent verification of the instantaneous power generation data specifically includes: The verification record is obtained from the trusted state consensus ledger described in S6; After obtaining the verification record, the cryptographic hash is generated by recalculating the metadata data to be verified, and the recalculated cryptographic hash is compared with the cryptographic hash contained in the verification record to generate a hash comparison result. When the hash comparison result is consistent, the validity of the federal signature contained in the verification record is verified using the federal public key.

8. The method for cross-platform verification of photovoltaic power generation data according to claim 1, characterized in that, The preset aggregation function mentioned in S5 is a function based on cryptographic group addition, used to combine multiple collected partial signatures into a single federated signature. The specific calculation method of the aggregation function is expressed as follows: ； in, For the federal signature, For the collected number Each part of the signature, The number of partial signatures is not less than the preset threshold.

9. The method and system for cross-platform verification of photovoltaic power generation data according to claim 1, characterized in that, The physical fingerprint has a one-to-one correspondence with the unique identifier of the device, and is used to uniquely identify the photovoltaic power generation device.

10. A cross-platform verification system for photovoltaic power generation data, characterized in that, The method for cross-platform verification of photovoltaic power generation data according to any one of claims 9 includes: A receiving module is used to receive metadata data from the edge of a photovoltaic power station. The metadata data contains a physical fingerprint associated with instantaneous power generation data, generated in real time based on a dynamic challenge code generated by a public physical beacon. The first signature module, located on the first platform server, is used to generate a first partial signature based on the cryptographic hash of the meta data packet and the first private key fragment held by the first platform server. The second signature module, located at at least one second platform server, is used to generate a second signature based on the cryptographic hash and a second private key fragment held by the second platform server after the physical correlation verification of the cryptographic hash has passed. An aggregation module is used to aggregate the first part of the signature and the second part of the signature into a federated signature when the number of partial signatures for the cryptographic hash reaches a preset threshold. And a storage module for storing the cryptographic hash and the federated signature as verification records in a trusted state consensus ledger.

Images