A zero-carbon footprint real-time monitoring method and terminal system

Abstract

The application discloses a kind of zero carbon footprint real-time monitoring method and terminal system, belong to carbon footprint monitoring technical field, its method specifically includes: obtaining the carbon emission data of industrial equipment, carbon emission data block is generated according to preset time interval, and the carbon emission data block is written into block chain, the carbon emission data block is handled by consensus, and the sensor parameter data of industrial equipment is collected, constructs the redundant feature vector based on the sensor parameter data, constructs behavior feature model based on historical reporting behavior parameter, compares current reporting behavior deviation, triggers collaborative challenge when deviation exceeds threshold value, constructs inter-node verification relationship graph and calculates abnormal propagation degree index, identifies abnormal node and writes result into block chain;The application improves the data authenticity and abnormal identification accuracy of carbon monitoring, and is suitable for the credible collection, verification and abnormal identification of industrial carbon emission data in multi-agent collaborative environment.

Description

Technical Field

[0001] This invention belongs to the field of carbon footprint monitoring technology, specifically a method and terminal system for real-time monitoring of zero carbon footprint. Background Technology

[0002] As the main carbon emitters, the accurate monitoring and transparent disclosure of the carbon footprint of industrial enterprises has become a key foundation for environmental regulation, carbon trading accounting, and corporate social responsibility reporting.

[0003] Currently, in terms of carbon emission monitoring technology, common solutions mainly rely on enterprises' self-built emission monitoring systems, such as online flue gas monitoring systems and energy consumption statistics systems, to generate carbon emission reports through periodic sampling, data reporting, or manual review. However, these methods generally have the following technical limitations: insufficient data reliability, the possibility of data falsification; weak data tampering detection capabilities, lack of verification mechanisms, and inability to identify abnormal behavior.

[0004] Introducing blockchain into carbon footprint monitoring scenarios can build a more trustworthy framework for carbon data on-chaining and verification. However, how to implement a zero-carbon footprint monitoring method on the blockchain remains a problem that urgently needs to be solved by current technology. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention proposes a real-time monitoring method and terminal system for zero carbon footprint.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] A method for real-time monitoring of zero carbon footprint includes:

[0008] Acquire carbon emission data from industrial equipment, generate carbon emission data blocks at preset time intervals, and write the carbon emission data blocks into the blockchain.

[0009] Consensus processing is performed on the carbon emission data block, and sensor parameter data of industrial equipment is collected to construct a redundant feature vector based on the sensor parameter data.

[0010] Based on the historical carbon emission reporting data and historical reporting behavior parameters of enterprise nodes, a behavior feature model is constructed, and the deviation between the current reporting behavior parameters and the historical reporting behavior parameters is compared. If the deviation exceeds a preset threshold, a collaborative challenge request is sent to the enterprise node.

[0011] Construct a data verification graph containing the interaction relationships between nodes, identify abnormal nodes, and write the abnormal nodes and their corresponding data into the blockchain.

[0012] Specifically, the consensus processing of the carbon emission data block and the collection of sensor parameter data from industrial equipment to construct a redundant feature vector based on the sensor parameter data include:

[0013] The carbon emission data block is broadcast to pre-authorized nodes in the blockchain, and the pre-authorized nodes confirm consistency through a preset consensus mechanism.

[0014] Write the confirmed valid carbon emission data blocks into the local ledger;

[0015] Collect sensor parameter data from industrial equipment, including: carbon dioxide concentration, oxygen content, exhaust temperature, and power consumption;

[0016] Based on the collected sensor parameter data, a redundant feature vector is constructed, and a mapping relationship between the equipment's operating status and carbon emission values ​​is established.

[0017] Specifically, based on the historical carbon emission reporting data and historical reporting behavior parameters of enterprise nodes, a behavioral feature model is constructed, and the deviation between the current reported behavior parameters and the historical reported behavior parameters is compared. If the deviation exceeds a preset threshold, a collaborative challenge request is sent to the enterprise node, including:

[0018] Within a preset time window, historical reporting behavior parameters are extracted based on the historical carbon emission data of enterprise nodes and the mapping relationship between equipment working status and carbon emission values. A behavior feature model is constructed, and the historical reporting behavior includes reporting frequency, numerical variation range, reporting time distribution and data format structure.

[0019] Input the currently reported data into the behavior feature model to obtain the behavior parameters corresponding to the currently reported data;

[0020] Calculate the deviation between the behavioral parameters corresponding to the currently reported data and the historically reported behavioral parameters;

[0021] If the deviation exceeds the preset threshold, mark the current enterprise node as a node to be verified and initiate a collaborative challenge request to the current node to be verified.

[0022] Specifically, the construction of a behavioral characteristic model based on historical carbon emission reporting data and historical reporting behavior parameters of enterprise nodes includes:

[0023] Acquire historical carbon emission data of enterprise nodes within a preset time window. The historical carbon emission data includes reporting timestamp, emission value, and data structure identifier field.

[0024] The historical carbon emission data is structured and parsed to extract historical reporting behavior parameters, including reporting frequency, range of numerical variation, distribution of reporting time, and data format structure.

[0025] The historical reported behavior parameters for each dimension are converted into numerical vectors, and then standardized and combined to obtain the processed historical reported behavior parameters.

[0026] A recurrent neural network model is used to train the processed historical reported behavior parameters to construct a behavior feature model.

[0027] Specifically, if the deviation exceeds a preset threshold, the current enterprise node is marked as a node to be verified, and a collaborative challenge request is initiated against the current node to be verified, including:

[0028] Enterprise nodes whose deviation exceeds the threshold are designated as nodes to be verified.

[0029] Select collaborative query nodes that do not belong to the enterprise to be verified; the selection is based on preset rules.

[0030] A collaborative challenge request data packet is constructed based on the collaborative challenge node. The collaborative challenge request data packet includes the identifier of the node to be verified, the summary information of the data to be challenged, the challenge parameter type identifier, and the data timestamp.

[0031] Broadcast the collaborative challenge request data packet to the collaborative challenge node and generate a corresponding verification response data packet for the challenge data;

[0032] Perform a difference analysis between the verification response data packet and the data of the node to be verified, and write the analysis results into the blockchain.

[0033] Specifically, broadcasting the collaborative challenge request data packet to the collaborative challenge node and generating a verification response data packet corresponding to the challenge data includes:

[0034] Broadcast the collaborative challenge request data packet to the collaborative challenge node to query the local ledger or collect similar parameter data corresponding to the collaborative challenge request data packet;

[0035] Extract response summaries for data with similar parameters, including data source type identifier, response parameter values, and response data timestamps;

[0036] The response digest is signed using the private key of the collaborative challenge node to generate a digitally signed verification response packet;

[0037] The verification response data packet is obtained by appending the public identification information of the collaborative challenge node and the verification timestamp to the verification response packet.

[0038] Specifically, the construction of a data verification graph containing the interaction relationships between nodes, the identification of abnormal nodes, and the writing of abnormal nodes and their corresponding data into the blockchain include:

[0039] A data verification graph is constructed to represent the interaction relationships between nodes. The nodes in the data verification graph are enterprise nodes, and the edges in the data verification graph represent the response behaviors and verification interactions between nodes.

[0040] Each edge in the data verification graph is assigned a weight, which is calculated from the deviation between the verification response data packet and the data to be verified, the response time delay, and the historical consistency of the nodes.

[0041] Calculate the anomaly propagation index of the node to be verified, which is based on the average weight of the edges connected to the node to be verified, the number of historical verification anomalies, and the betweenness centrality value of the node to be verified in the data verification graph.

[0042] If the abnormal propagation index of the node to be verified exceeds the preset threshold, the node to be verified will be marked as an abnormal node, and the abnormal node record data block will be written into the blockchain. The abnormal node record data block includes abnormal node consensus, abnormal propagation index, and verification deviation record.

[0043] Specifically, the steps of acquiring carbon emission data from industrial equipment, generating carbon emission data blocks at preset time intervals, and writing the carbon emission data blocks into the blockchain include:

[0044] Collect carbon emission data from industrial equipment;

[0045] The carbon emission data is grouped according to a preset time interval to form multiple carbon emission data segments, each carbon emission data segment corresponding to a time window;

[0046] Each carbon emission data segment is preprocessed, including noise removal, outlier handling, and standardization.

[0047] Each preprocessed carbon emission data segment is appended with the current master clock time to generate a timestamp, and a hash calculation is performed on the carbon emission data segment and its timestamp content to generate a corresponding hash fingerprint;

[0048] The hash fingerprint is combined with the corresponding carbon emission data segment to form a carbon emission data block, and the carbon emission data block is written into the blockchain.

[0049] A zero-carbon footprint real-time monitoring terminal system is used to implement the aforementioned zero-carbon footprint real-time monitoring method, comprising: a data acquisition module, a redundant feature construction module, a challenge request module, and an anomaly identification module;

[0050] The data acquisition module is used to acquire carbon emission data of industrial equipment, generate carbon emission data blocks at preset time intervals, and write the carbon emission data blocks into the blockchain.

[0051] The redundant feature construction module is used to perform consensus processing on the carbon emission data block, collect sensor parameter data of industrial equipment, and construct a redundant feature vector based on the sensor parameter data.

[0052] The challenge request module is used to construct a behavior feature model based on the historical carbon emission reporting data and historical reporting behavior parameters of the enterprise node, and compare the deviation between the current reporting behavior parameters and the historical reporting behavior parameters. If the deviation exceeds a preset threshold, a collaborative challenge request is sent to the enterprise node.

[0053] The anomaly identification module is used to construct a data verification graph containing the interaction relationships between nodes, identify abnormal nodes, and write the abnormal nodes and their corresponding data into the blockchain.

[0054] Specifically, the challenge request module includes: a model building unit, a deviation calculation unit, and a challenge request unit;

[0055] The model building unit is used to extract historically reported behavioral parameters based on the historical carbon emission data of enterprise nodes and the mapping relationship between equipment working status and carbon emission values ​​within a preset time window, and to train the processed historically reported behavioral parameters using a recurrent neural network model to build a behavioral feature model.

[0056] The deviation calculation unit is used to calculate the deviation between the behavior parameters corresponding to the currently reported data and the historically reported behavior parameters;

[0057] The challenge request unit is used to mark the current enterprise node as a node to be verified and initiate a collaborative challenge request to the current node to be verified when the deviation exceeds a preset threshold.

[0058] Compared with the prior art, the beneficial effects of the present invention are:

[0059] 1. This invention proposes a real-time monitoring method and terminal system for zero carbon footprint. By segmenting, timestamping, and generating hash fingerprints from carbon emission data of industrial equipment, and combining blockchain on-chain notarization and multi-node consensus mechanisms, it achieves reliable collection and tamper-proof recording of carbon emission data. It introduces multi-sensor redundant data modeling to improve data verification capabilities, and constructs a behavioral feature model based on the enterprise's historical reporting behavior to analyze the deviation of current data reporting behavior, effectively identifying potential abnormal reporting. Furthermore, through a cross-node collaborative questioning mechanism and a graph structure verification model, it automatically identifies and locates enterprise nodes with data fraud behavior and archives the data, thereby improving the data authenticity, anomaly identification accuracy, and traceability capabilities of carbon monitoring. Attached Figure Description

[0060] Figure 1 A flowchart of a real-time monitoring method for zero carbon footprint provided by the present invention;

[0061] Figure 2 A flowchart for the inquiry application process is provided for this invention;

[0062] Figure 3 This is a schematic diagram of data verification provided by the present invention;

[0063] Figure 4 This invention provides an architecture diagram of a real-time monitoring terminal system for zero carbon footprint. Detailed Implementation

[0064] The present application will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present application, but do not limit the present application in any way. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of the present application. These all fall within the protection scope of the present application.

[0065] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0066] It should be noted that, unless there is conflict, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described can be performed in a different order than the module division in the device or the order in the flowchart. In addition, the "

[0067] The terms "first," "second," and "third" do not limit the data or execution order; they are merely used to distinguish identical or similar items with essentially the same function and purpose.

[0068] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0069] Example 1

[0070] Please see Figures 1-3 The present invention provides an embodiment of a method for real-time monitoring of zero carbon footprint, comprising the following specific steps:

[0071] Step S1: Obtain carbon emission data from industrial equipment, generate carbon emission data blocks at preset time intervals, and write the carbon emission data blocks into the blockchain.

[0072] The specific steps of step S1 are as follows:

[0073] Step S101: Collect carbon emission data from industrial equipment.

[0074] Step S102: The carbon emission data is grouped according to a preset time interval to form multiple carbon emission data segments, each carbon emission data segment corresponding to a time window.

[0075] Step S103: Preprocess each carbon emission data segment, including noise removal, outlier handling, and standardization.

[0076] It should be noted that the preprocessing adopts existing technical methods, such as noise reduction using moving average or median filtering, outlier processing using Z-score method or live box plot method, and standardization using Z-score processing. This application will not elaborate on these methods.

[0077] Step S104: Add the current master clock time to each preprocessed carbon emission data segment to generate a timestamp, and perform hash calculation on the carbon emission data segment and its timestamp content to generate the corresponding hash fingerprint.

[0078] Step S105: Combine the hash fingerprint with the corresponding carbon emission data segment to form a carbon emission data block, and write the carbon emission data block into the blockchain.

[0079] In this embodiment, each carbon emission data block is essentially a structured data unit, including the original data segment content, timestamp, and hash value. This data is encapsulated into a structure format as the block body content.

[0080] In traditional carbon emission monitoring, the collected data is only stored on local servers or uploaded to centralized regulatory platforms, which poses a risk of modification or loss. Furthermore, the authenticity of modified data cannot be verified. This application transforms the original data segments into carbon emission data blocks with timestamps and hash verification. By writing the data into a blockchain system, it achieves data tamper-proofing, trusted recording, and distributed consensus. The authenticity of the modified data is then verified in subsequent steps.

[0081] Step S2: Perform consensus processing on the carbon emission data block, collect sensor parameter data from industrial equipment, and construct a redundant feature vector based on the sensor parameter data.

[0082] The specific steps of step S2 are as follows:

[0083] Step S201: Broadcast the carbon emission data block to the pre-authorized nodes in the blockchain, and the pre-authorized nodes confirm the consistency through a preset consensus mechanism.

[0084] In this embodiment, a pre-authorized node refers to a node that has passed identity authentication or access control. It sends carbon emission data to various pre-authorized nodes through the blockchain network. Each node uses preset rules to verify the data structure, hash validity, and timestamp validity. If more than 2 / 3 of the nodes reach a consensus, the data block is considered to be legitimate data.

[0085] Step S202: Write the confirmed valid carbon emission data block into the local ledger.

[0086] In this embodiment, the local ledger refers to a copy of the data maintained locally by each node and kept synchronized with other nodes.

[0087] Step S203: Collect sensor parameter data of industrial equipment, including carbon dioxide concentration, oxygen content, exhaust temperature, and power consumption.

[0088] Step S204: Construct a redundant feature vector based on the collected sensor parameter data, and establish a mapping relationship between the equipment's operating status and carbon emission values.

[0089] In this embodiment, a correlation model between redundant parameters and actual emission data is established using historical training datasets. The redundant parameters are sensor parameter data. Specifically, samples are extracted from confirmed data within a certain time range to construct a redundant feature vector matrix, obtain the target carbon emission value, and establish a mapping function using methods such as multiple linear regression or support vector machine.

[0090] Step S3: Based on the historical carbon emission reporting data and historical reporting behavior parameters of the enterprise node, construct a behavior feature model, and compare the deviation between the current reported behavior parameters and the historical reported behavior parameters. If the deviation exceeds a preset threshold, send a collaborative challenge request to the enterprise node.

[0091] like Figure 2 As shown, the specific steps of step S3 are as follows:

[0092] Step S301: Within a preset time window, extract historical reporting behavior parameters based on the historical carbon emission data of enterprise nodes and the mapping relationship between equipment operating status and carbon emission values, and construct a behavior feature model. The historical reporting behavior includes reporting frequency, numerical variation range, reporting time distribution, and data format structure.

[0093] The specific steps of step S301 are as follows:

[0094] Step S3011: Obtain historical carbon emission data of the enterprise node within a preset time window. The historical carbon emission data includes the reporting timestamp, emission value, and data structure identifier field.

[0095] Step S3012: Perform structured analysis on the historical carbon emission data to extract historical reporting behavior parameters, including reporting frequency, numerical variation range, reporting time distribution, and data format structure.

[0096] In this embodiment, behavioral characteristics and carbon emission behavior are presented as non-data layer pattern information. If a company falsifies data, the following typical behaviors will occur: irregular mutations, abnormal reporting formats, and abnormal reporting frequency and intervals. For example, no reporting during the day, but high-density reporting at night.

[0097] Step S3013: Convert the historical reported behavior parameters of each dimension into numerical vectors, and perform standardization and combination to obtain the processed historical reported behavior parameters.

[0098] Step S3014: Use a recurrent neural network model to train the processed historical reported behavior parameters and construct a behavior feature model.

[0099] In this embodiment, the reporting behavior is a time-dependent data, such as enterprises reporting frequently in the morning and stopping in the evening, or enterprises reporting data in a concentrated manner at the end of the month. The RNN uses this sequentiality to remember historical behavior in the model weights for predicting the current behavior. Specifically, a training dataset is constructed, which is the processed historical reporting behavior parameters. Training parameters are set, including the number of training rounds and network parameters. A loss function is selected for training until the error between the actual behavior and the predicted behavior is minimized and the training stops.

[0100] Step S302: Input the currently reported data into the behavior feature model to obtain the behavior parameters corresponding to the currently reported data.

[0101] Step S303: Calculate the deviation between the behavioral parameters corresponding to the currently reported data and the historically reported behavioral parameters.

[0102] Step S304: If the deviation exceeds the preset threshold, mark the current enterprise node as a node to be verified and initiate a collaborative challenge request to the current node to be verified.

[0103] The specific steps of step S304 are as follows:

[0104] Step S3041: Mark enterprise nodes whose deviation exceeds the threshold as nodes to be verified.

[0105] Step S3042: Select a collaborative query node that does not belong to the enterprise to be verified. The selection is based on preset rules.

[0106] Specifically, the preset rules include nodes belonging to the same group of enterprises, geographically adjacent nodes, and nodes with similar equipment structures.

[0107] Step S3043: Construct a collaborative challenge request data packet based on the collaborative challenge node. The collaborative challenge request data packet includes the identifier of the node to be verified, the summary information of the data to be challenged, the challenge parameter type identifier, and the data timestamp.

[0108] Step S3044: Broadcast the collaborative challenge request data packet to the collaborative challenge node and generate a verification response data packet corresponding to the challenge data.

[0109] The specific steps of step S3044 are as follows:

[0110] Step S3044-1: Broadcast the collaborative challenge request data packet to the collaborative challenge node, query the local ledger, or collect similar parameter data corresponding to the collaborative challenge request data packet.

[0111] In this embodiment, after receiving the collaborative challenge request data packet, the collaborative challenge node retrieves data in its ledger that matches the specified timestamp. If there is no record in the ledger, it collects parameters such as CO2 and energy consumption in real time through its own device to achieve dual backup of the data acquisition path.

[0112] Step S3044-2: Extract response summaries of similar parameter data, including data source type identifier, response parameter values, and response data timestamps.

[0113] In this embodiment, response summaries of similar parameter data are extracted. First, the parameter type and target timestamp are identified, corresponding values ​​are collected from the ledger or device and the data source type is marked, and finally, a response summary structure is constructed.

[0114] In blockchain collaborative challenge, the original collaborative challenge request data packet has the following characteristics: large size, containing multiple parameter fields and metadata, resulting in high transmission and signing costs; privacy concerns, such as the difficulty in leaking enterprise energy consumption indicators and production environment. Therefore, it is necessary to process the original collaborative challenge request data packet and extract the response digest to provide sufficient verification information and ensure data lightweighting.

[0115] Step S3044-3: Sign the response digest using the private key of the collaborative challenge node to generate a digitally signed verification response packet.

[0116] Step S3044-4: Attach the public identifier information of the collaborative challenge node and the verification timestamp to the verification response packet to obtain the verification response data packet.

[0117] Step S3045: Perform a difference analysis between the verification response data packet and the data of the node to be verified, and write the analysis results into the blockchain.

[0118] Specifically, the verification response data packet is compared with the data of the node to be verified, the numerical distance between these values ​​is calculated, and all the numerical distance results, the original verification response data packet and the data of the node to be verified are written into the blockchain.

[0119] In this embodiment, this step constructs a carbon emission reporting behavior model of enterprise nodes within a preset time window, extracts and quantifies historical behavioral characteristics including reporting frequency, numerical variation range, time distribution, and data format structure, forming a behavioral baseline with node characteristics. By comparing the deviation of behavioral parameters of the current reported data, suspicious nodes with significantly deviated behavioral patterns can be dynamically identified, thereby avoiding misjudgments caused by relying solely on numerical judgments. Furthermore, a collaborative questioning mechanism triggered by the deviation is used to achieve cross-validation of data among multiple nodes, effectively enhancing the ability to determine the authenticity of carbon emission data and improving the early warning and tracking capabilities for potential data tampering and forgery.

[0120] Step S4: Construct a data verification graph containing the interaction relationships between nodes, identify abnormal nodes, and write the abnormal nodes and their corresponding data into the blockchain.

[0121] like Figure 3 As shown, the specific steps of step S4 are as follows:

[0122] Step S401: Construct a data verification graph of the interaction relationship between nodes. The nodes in the data verification graph are enterprise nodes, and the edges in the data verification graph represent the response behavior and verification interaction between nodes.

[0123] Step S402: Assign a weight to each edge in the data verification graph. The weight is calculated from the deviation between the verification response data packet and the data to be verified, the response time delay, and the historical consistency of the nodes.

[0124] In this embodiment, a single factor (such as the deviation value) is difficult to comprehensively evaluate the reliability of a certain verification behavior. For example, although the response value of a certain node is accurate, the delay is serious because it is returned after offline modification; a certain node's response deviates occasionally, but its long-term historical consistency is very high, which is an occasional error; by using a weighting mechanism to integrate the three factors to generate the final edge weight, the reliability of the weight is improved.

[0125] Step S403: Calculate the anomaly propagation index of the node to be verified. The anomaly propagation index is based on the average weight of the edges connected to the node to be verified, the number of historical verification anomalies, and the betweenness centrality value of the node to be verified in the data verification graph.

[0126] In this embodiment, relying solely on a single deviation or a failed inquiry result to determine whether a company's data is falsified could lead to a misjudgment. Therefore, this application introduces an anomaly propagation index to identify abnormal nodes or high-risk nodes that affect the judgment of other nodes.

[0127] Specifically, the average weight of the edges connected to the node to be verified reflects the degree of acceptance by other nodes after being challenged; the number of historical verification anomalies reflects whether it frequently triggered challenges but failed verification in the past; the betweenness centrality value of the node to be verified's position in the data verification graph indicates the degree to which the node to be verified controls the information transmission path in the data verification graph, and the higher the value, the more likely it is to act as an intermediary node that influences other nodes. Figure 3 In this process, the node to be verified can participate in collaborative verification among multiple other nodes. It is a key node on multiple verification paths, meaning that many verification paths between nodes require passing through the node to be verified, thus giving it high control. Figure 3 The graph only shows one node to be verified and multiple collaborative challenge nodes. If one of the collaborative challenge nodes is determined to be a node to be verified, it is necessary to go through the original node to be verified. The original node to be verified can be determined as a key node. The specific calculation method of the betweenness centrality value is as follows: find the shortest path between all node pairs in the data verification graph, count how many shortest paths will pass through the node to be verified, and divide the number of paths passing through the node to be verified by the total number of paths to obtain the betweenness centrality value of the node.

[0128] Step S404: If the abnormal propagation index of the node to be verified exceeds the preset threshold, the node to be verified is marked as an abnormal node, and the abnormal node record data block is written into the blockchain. The abnormal node record data block includes abnormal node consensus, abnormal propagation index and verification deviation record.

[0129] In this embodiment, data fluctuations are normal in actual industrial monitoring networks. In existing technologies, it is difficult to analyze data falsification based on the data of a certain node and its historical data. Even if falsification is possible, it cannot be directly identified as falsification. This application introduces blockchain, which uses verification response data packets from multiple collaborative questioning nodes to perform statistical comparative analysis with the data of the node to be verified to determine whether it deviates significantly from the group consistency. Then, it calculates the abnormal propagation index of the node to be verified and determines whether it is an abnormal node based on the abnormal propagation index. The advantage of this approach is that once the data is recorded on the blockchain, it cannot be deleted and becomes a permanent record of behavior. It is only necessary to consider whether falsification occurred during the reporting process. Through the cross-node collaborative questioning mechanism and graph structure verification model, enterprise nodes with data falsification behavior are automatically identified and located, and abnormal nodes and data are archived, thereby improving the data authenticity of carbon monitoring.

[0130] Example 2

[0131] Please see Figure 4Another embodiment of the present invention provides: a zero carbon footprint real-time monitoring terminal system, comprising: a data acquisition module, a redundancy feature construction module, a challenge request module and an anomaly identification module;

[0132] The data acquisition module is used to acquire carbon emission data of industrial equipment, generate carbon emission data blocks at preset time intervals, and write the carbon emission data blocks into the blockchain.

[0133] The redundant feature construction module is used to perform consensus processing on the carbon emission data block, collect sensor parameter data of industrial equipment, and construct a redundant feature vector based on the sensor parameter data.

[0134] The challenge request module is used to construct a behavior feature model based on the historical carbon emission reporting data and historical reporting behavior parameters of the enterprise node, and compare the deviation between the current reporting behavior parameters and the historical reporting behavior parameters. If the deviation exceeds a preset threshold, a collaborative challenge request is sent to the enterprise node.

[0135] The anomaly identification module is used to construct a data verification graph containing the interaction relationships between nodes, identify abnormal nodes, and write the abnormal nodes and their corresponding data into the blockchain.

[0136] The challenge request module includes: a model building unit, a deviation calculation unit, and a challenge request unit;

[0137] The model building unit is used to extract historically reported behavioral parameters based on the historical carbon emission data of enterprise nodes and the mapping relationship between equipment working status and carbon emission values ​​within a preset time window, and to train the processed historically reported behavioral parameters using a recurrent neural network model to build a behavioral feature model.

[0138] The deviation calculation unit is used to calculate the deviation between the behavior parameters corresponding to the currently reported data and the historically reported behavior parameters;

[0139] The challenge request unit is used to mark the current enterprise node as a node to be verified and initiate a collaborative challenge request to the current node to be verified when the deviation exceeds a preset threshold.

[0140] In addition, the parts of the technical solutions provided in the embodiments of this application that are consistent with the implementation principles of the corresponding technical solutions in the prior art have not been described in detail, so as to avoid excessive elaboration.

[0141] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for real-time monitoring of zero carbon footprint, characterized in that, include: Acquire carbon emission data from industrial equipment, generate carbon emission data blocks at preset time intervals, and write the carbon emission data blocks into the blockchain; Consensus processing is performed on the carbon emission data block, and sensor parameter data of industrial equipment is collected to construct a redundant feature vector based on the sensor parameter data. Based on the historical carbon emission reporting data and historical reporting behavior parameters of enterprise nodes, a behavior feature model is constructed, and the deviation between the current reporting behavior parameters and the historical reporting behavior parameters is compared. If the deviation exceeds a preset threshold, a collaborative challenge request is sent to the enterprise node. Construct a data verification graph containing the interaction relationships between nodes, identify abnormal nodes, and write the abnormal nodes and their corresponding data into the blockchain; The consensus processing of the carbon emission data block and the collection of sensor parameter data from industrial equipment to construct a redundant feature vector based on the sensor parameter data include: The carbon emission data block is broadcast to pre-authorized nodes in the blockchain, and the pre-authorized nodes confirm consistency through a preset consensus mechanism. Write the confirmed valid carbon emission data blocks into the local ledger; Collect sensor parameter data from industrial equipment, including: carbon dioxide concentration, oxygen content, exhaust temperature, and power consumption; Based on the collected sensor parameter data, a redundant feature vector is constructed, and a mapping relationship between the equipment's operating status and carbon emission values ​​is established. The system constructs a behavioral feature model based on historical carbon emission reporting data and historical reporting behavior parameters of enterprise nodes. It then compares the deviation between the current reported behavior parameters and historical reported behavior parameters. If the deviation exceeds a preset threshold, a collaborative challenge request is sent to the enterprise node, including: Within a preset time window, historical reporting behavior parameters are extracted based on the historical carbon emission data of enterprise nodes and the mapping relationship between equipment working status and carbon emission values. A behavior feature model is constructed, and the historical reporting behavior includes reporting frequency, numerical variation range, reporting time distribution and data format structure. Input the currently reported data into the behavior feature model to obtain the behavior parameters corresponding to the currently reported data; Calculate the deviation between the behavioral parameters corresponding to the currently reported data and the historically reported behavioral parameters; If the deviation exceeds the preset threshold, mark the current enterprise node as a node to be verified and initiate a collaborative challenge request for the current node to be verified. The behavioral characteristic model is constructed based on the historical carbon emission reporting data and historical reporting behavior parameters of enterprise nodes, including: Acquire historical carbon emission data of enterprise nodes within a preset time window. The historical carbon emission data includes reporting timestamp, emission value, and data structure identifier field. The historical carbon emission data is structured and parsed to extract historical reporting behavior parameters, including reporting frequency, range of numerical variation, distribution of reporting time, and data format structure. The historical reported behavior parameters for each dimension are converted into numerical vectors, and then standardized and combined to obtain the processed historical reported behavior parameters. A recurrent neural network model is used to train the processed historical reported behavior parameters to construct a behavior feature model; If the deviation exceeds a preset threshold, the current enterprise node is marked as a node to be verified, and a collaborative challenge request is initiated against the current node to be verified, including: Enterprise nodes whose deviation exceeds the threshold are designated as nodes to be verified. Select collaborative query nodes that do not belong to the enterprise to be verified; the selection is based on preset rules. A collaborative challenge request data packet is constructed based on the collaborative challenge node. The collaborative challenge request data packet includes the identifier of the node to be verified, the summary information of the data to be challenged, the challenge parameter type identifier, and the data timestamp. Broadcast the collaborative challenge request data packet to the collaborative challenge node and generate a corresponding verification response data packet for the challenge data; Perform a difference analysis between the verification response data packet and the data of the node to be verified, and write the analysis results into the blockchain; The step of broadcasting the collaborative challenge request data packet to the collaborative challenge node and generating a verification response data packet corresponding to the challenge data includes: Broadcast the collaborative challenge request data packet to the collaborative challenge node to query the local ledger or collect similar parameter data corresponding to the collaborative challenge request data packet; Extract response summaries for data with similar parameters, including data source type identifier, response parameter values, and response data timestamps; The response digest is signed using the private key of the collaborative challenge node to generate a digitally signed verification response packet; The verification response data packet is obtained by appending the public identification information of the collaborative challenge node and the verification timestamp to the verification response packet. The process of constructing a data verification graph containing the interaction relationships between nodes, identifying abnormal nodes, and writing the abnormal nodes and their corresponding data into the blockchain includes: A data verification graph is constructed to represent the interaction relationships between nodes. The nodes in the data verification graph are enterprise nodes, and the edges in the data verification graph represent the response behaviors and verification interactions between nodes. Each edge in the data verification graph is assigned a weight, which is calculated from the deviation between the verification response data packet and the data to be verified, the response time delay, and the historical consistency of the nodes. Calculate the anomaly propagation index of the node to be verified, which is based on the average weight of the edges connected to the node to be verified, the number of historical verification anomalies, and the betweenness centrality value of the node to be verified in the data verification graph. If the abnormal propagation index of the node to be verified exceeds the preset threshold, the node to be verified will be marked as an abnormal node, and the abnormal node record data block will be written into the blockchain. The abnormal node record data block includes abnormal node consensus, abnormal propagation index, and verification deviation record.

2. The method for real-time monitoring of zero carbon footprint as described in claim 1, characterized in that, The process of acquiring carbon emission data from industrial equipment, generating carbon emission data blocks at preset time intervals, and writing the carbon emission data blocks into the blockchain includes: Collect carbon emission data from industrial equipment; The carbon emission data is grouped according to a preset time interval to form multiple carbon emission data segments, each carbon emission data segment corresponding to a time window; Each carbon emission data segment is preprocessed, including noise removal, outlier handling, and standardization. Each preprocessed carbon emission data segment is appended with the current master clock time to generate a timestamp, and a hash calculation is performed on the carbon emission data segment and its timestamp content to generate a corresponding hash fingerprint; The hash fingerprint is combined with the corresponding carbon emission data segment to form a carbon emission data block, and the carbon emission data block is written into the blockchain.

3. A zero-carbon footprint real-time monitoring terminal system, used to implement the zero-carbon footprint real-time monitoring method according to any one of claims 1-2, characterized in that, include: Data acquisition module, redundant feature construction module, challenge request module, and anomaly identification module; The data acquisition module is used to acquire carbon emission data of industrial equipment, generate carbon emission data blocks at preset time intervals, and write the carbon emission data blocks into the blockchain. The redundant feature construction module is used to perform consensus processing on the carbon emission data block, collect sensor parameter data of industrial equipment, and construct a redundant feature vector based on the sensor parameter data. The challenge request module is used to construct a behavior feature model based on the historical carbon emission reporting data and historical reporting behavior parameters of the enterprise node, and compare the deviation between the current reporting behavior parameters and the historical reporting behavior parameters. If the deviation exceeds a preset threshold, a collaborative challenge request is sent to the enterprise node. The anomaly identification module is used to construct a data verification graph containing the interaction relationships between nodes, identify abnormal nodes, and write the abnormal nodes and their corresponding data into the blockchain.

4. The zero-carbon footprint real-time monitoring terminal system as described in claim 3, characterized in that, The challenge request module includes: a model building unit, a deviation calculation unit, and a challenge request unit; The model building unit is used to extract historically reported behavioral parameters based on the historical carbon emission data of enterprise nodes and the mapping relationship between equipment working status and carbon emission values ​​within a preset time window, and to train the processed historically reported behavioral parameters using a recurrent neural network model to build a behavioral feature model. The deviation calculation unit is used to calculate the deviation between the behavior parameters corresponding to the currently reported data and the historically reported behavior parameters; The challenge request unit is used to mark the current enterprise node as a node to be verified and initiate a collaborative challenge request to the current node to be verified when the deviation exceeds a preset threshold.

Images