Carbon data transmission method and device, computer equipment and readable storage medium

Abstract

The application relates to a carbon data transmission method and device, computer equipment and a readable storage medium. The method comprises the following steps: obtaining the device identifiers of a plurality of power-using devices; for each device identifier, calling a driving module matched with the device identifier to detect the carbon data of the power-using device matched with the device identifier by using the protocol in the driving module; wherein the protocol associated with the device identifier is encapsulated in the driving module; performing semantic extraction on the carbon data of the plurality of power-using devices to obtain carbon semantic data of the plurality of power-using devices; fusing the carbon semantic data of the plurality of power-using devices to obtain fused carbon data; and transmitting the fused carbon data to a block chain. The method can efficiently perform carbon data transmission.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a carbon data transmission method, apparatus, computer device, and readable storage medium. Background Technology

[0002] With the advancement of "data elementization" and "carbon data ownership verification," more and more systems are attempting to store carbon data using blockchain. Therefore, how to transfer carbon data to the blockchain has become a topic of great interest.

[0003] In traditional technologies, various smart meters, circuit breakers, inverters, sensors, and other electrical devices are widely deployed at carbon emission sources such as enterprises, industrial parks, and communities, forming a massive heterogeneous carbon data collection network. At this time, solutions for transmitting carbon data to the blockchain include: monitoring the carbon data of electrical devices in real time through a protocol that supports carbon data collection from all electrical devices, encrypting the carbon data, and then inputting the encrypted carbon data into the blockchain to improve the security of carbon data transmission.

[0004] However, current carbon data transmission methods are not efficient enough. Summary of the Invention

[0005] Therefore, it is necessary to provide an efficient carbon data transmission method, apparatus, computer equipment, computer-readable storage medium, and computer program product to address the aforementioned technical problems.

[0006] In a first aspect, this application provides a carbon data transmission method, comprising:

[0007] Obtain device identifiers for multiple electrical devices;

[0008] For each device identifier, the driver module matching the device identifier is invoked to detect the carbon data of the electrical equipment matching the device identifier using the protocol in the driver module; wherein, the driver module encapsulates the protocol associated with the device identifier;

[0009] Semantic extraction is performed on the carbon data of multiple electrical devices to obtain carbon semantic data of multiple electrical devices;

[0010] The carbon semantic data of multiple electrical devices are fused to obtain fused carbon data.

[0011] The carbon data will be transferred to the blockchain.

[0012] In one embodiment, carbon semantic data from multiple electrical devices are fused to obtain fused carbon data, including:

[0013] Detect the historical communication status of multiple electrical devices;

[0014] Based on the historical communication status of multiple electrical devices, carbon semantic data from multiple electrical devices are fused to obtain fused carbon data.

[0015] In one embodiment, detecting the historical communication status of multiple electrical devices includes:

[0016] The historical transmission success rate and historical data fluctuation information of multiple electrical devices are detected. The historical transmission success rate represents the proportion of successfully transmitted data to the blockchain within a historical period to all pending communication data. The historical data fluctuation information represents the data fluctuation amplitude and data fluctuation frequency of the pending communication data of electrical devices during transmission within a historical period.

[0017] Based on the historical transmission success rate and historical data fluctuation information of each electrical device, the historical communication status of the corresponding electrical device is detected.

[0018] In one embodiment, carbon semantic data from multiple electrical devices are fused to obtain fused carbon data, including:

[0019] For each electrical device, the power consumption information, regional carbon factor information and collection timestamp information of the electrical device are extracted from the carbon semantic data. Based on the power consumption information, regional carbon factor information and collection timestamp information, the carbon data of the electrical device within the target time window is generated.

[0020] The carbon data of all electrical devices within the target time window are fused to obtain fused carbon data.

[0021] In one embodiment, transmitting fused carbon data to a blockchain includes:

[0022] Detect summary information of fused carbon data;

[0023] Using the pre-loaded private key, digitally sign the fused carbon data to obtain the signature information of the fused carbon data;

[0024] The digest information, signature information, and fused carbon data are combined, and the combined fused carbon data is transmitted to the blockchain.

[0025] In one embodiment, transmitting the combined fused carbon data to the blockchain includes:

[0026] The gateway on the blockchain side is controlled to extract the digest information, signature information and fused carbon data from the combined fused carbon data, and the gateway is controlled to perform consistency verification on the digest information and signature information respectively.

[0027] If the verification result characterization summary information is consistent with the standard summary information pre-stored by the gateway, and the signature information is consistent with the standard summary information pre-stored by the gateway, the fused carbon data will be written into the blockchain.

[0028] Secondly, this application also provides a carbon data transmission device, comprising:

[0029] The identifier acquisition module is used to acquire the device identifiers of multiple electrical devices.

[0030] The protocol parsing module is used to call the driver module that matches the device identifier for each device identifier, so as to use the protocol in the driver module to detect the carbon data of the electrical equipment that matches the device identifier; wherein, the driver module encapsulates the protocol associated with the device identifier;

[0031] The semantic extraction module is used to extract the semantics from the carbon data of multiple electrical devices to obtain the carbon semantic data of multiple electrical devices.

[0032] The data fusion module is used to fuse carbon semantic data from multiple electrical devices to obtain fused carbon data.

[0033] The data transmission module is used to transmit fused carbon data to the blockchain.

[0034] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0035] Obtain device identifiers for multiple electrical devices;

[0036] For each device identifier, the driver module matching the device identifier is invoked to detect the carbon data of the electrical equipment matching the device identifier using the protocol in the driver module; wherein, the driver module encapsulates the protocol associated with the device identifier;

[0037] Semantic extraction is performed on the carbon data of multiple electrical devices to obtain carbon semantic data of multiple electrical devices;

[0038] The carbon semantic data of multiple electrical devices are fused to obtain fused carbon data.

[0039] The carbon data will be transferred to the blockchain.

[0040] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0041] Obtain device identifiers for multiple electrical devices;

[0042] For each device identifier, the driver module matching the device identifier is invoked to detect the carbon data of the electrical equipment matching the device identifier using the protocol in the driver module; wherein, the driver module encapsulates the protocol associated with the device identifier;

[0043] Semantic extraction is performed on the carbon data of multiple electrical devices to obtain carbon semantic data of multiple electrical devices;

[0044] The carbon semantic data of multiple electrical devices are fused to obtain fused carbon data.

[0045] The carbon data will be transferred to the blockchain.

[0046] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0047] Obtain device identifiers for multiple electrical devices;

[0048] For each device identifier, the driver module matching the device identifier is invoked to detect the carbon data of the electrical equipment matching the device identifier using the protocol in the driver module; wherein, the driver module encapsulates the protocol associated with the device identifier;

[0049] Semantic extraction is performed on the carbon data of multiple electrical devices to obtain carbon semantic data of multiple electrical devices;

[0050] The carbon semantic data of multiple electrical devices are fused to obtain fused carbon data.

[0051] The carbon data will be transferred to the blockchain.

[0052] The aforementioned carbon data transmission methods, apparatuses, computer devices, computer-readable storage media, and computer program products currently suffer from low carbon data collection efficiency due to the complexity of communication protocols for electrical devices and the large number of such devices, which in turn affects the carbon data transmission process. Therefore, this application provides an efficient carbon data transmission method. Throughout the process, the protocol is encapsulated in the driver module, decoupling the protocol protocols of each electrical device. In other words, each driver module matching the device identifier encapsulates a protocol protocol matching the device identifier. Compared to the complex protocol protocols in the prior art that support the collection of carbon data from all electrical devices, the protocol protocol matching the device identifier in this application is simpler. Therefore, it can improve the efficiency of detecting carbon data from electrical devices with matching device identifiers, further improving the efficiency of carbon data transmission. At the same time, after detecting carbon data from multiple electrical devices with matching device identifiers, key semantic information can be extracted from the carbon data of the electrical devices, interference from irrelevant data can be removed, the amount of carbon data can be reduced, and the fused carbon data can then be efficiently transmitted to the blockchain. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0054] Figure 1 This is a diagram illustrating the application environment of a carbon data transmission method in one embodiment;

[0055] Figure 2 This is a flowchart illustrating a carbon data transmission method in one embodiment;

[0056] Figure 3 This is a flowchart illustrating the carbon data transmission method in another embodiment;

[0057] Figure 4 This is a flowchart illustrating a carbon data transmission method in a detailed embodiment;

[0058] Figure 5 This is a structural block diagram of a carbon data transmission device in one embodiment;

[0059] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0060] 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 for illustrative purposes only and are not intended to limit the scope of this application.

[0061] With the increasing sophistication of carbon data monitoring and management, various smart meters, circuit breakers, inverters, sensors, and other electrical devices are widely deployed at carbon emission sources such as enterprises, industrial parks, and communities, forming a massive, heterogeneous carbon emission data collection network. These devices are characterized by inconsistent communication protocols, diverse protocol types, and disorganized equipment types, resulting in low data collection and fusion efficiency, difficulty in ensuring data timeliness, and impacting subsequent carbon emission accounting, green certification, and compliance verification.

[0062] Therefore, there is an urgent need for an underlying mechanism that can build a "unified acquisition channel" in a heterogeneous terminal environment to realize the transmission of carbon data to the blockchain and support the construction of a reliable and real-time carbon data monitoring and transmission system.

[0063] The carbon data transmission method provided in this application can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with blockchain 106 via edge server 104. A data storage system can store the data that edge server 104 needs to process. The data storage system can be integrated onto edge server 104, or it can be located in the cloud or on other network servers.

[0064] On the carbon data processing interface of terminal 102, the user selects the device identifiers of multiple electrical devices for which carbon data is to be transmitted and triggers the carbon data on-chain control. Terminal 102 responds to the trigger request of the carbon data on-chain control, generates a carbon data transmission request, which carries the device identifiers of multiple electrical devices, and sends the carbon data transmission request to edge server 104. Edge server 104 obtains the device identifiers of multiple electrical devices. For each device identifier, it calls the driver module that matches the device identifier and uses the protocol in the driver module to detect the carbon data of the electrical device that matches the device identifier. The driver module encapsulates the protocol associated with the device identifier. Semantic extraction is performed on the carbon data of multiple electrical devices to obtain carbon semantic data of multiple electrical devices. The carbon semantic data of each electrical device is fused to obtain fused carbon data. The fused carbon data is then transmitted to blockchain 106.

[0065] The terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. Head-mounted devices can include virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. The edge server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0066] In one exemplary embodiment, such as Figure 2 As shown, a carbon data transmission method is provided, which can be applied to... Figure 1 The following explanation uses edge server 104 as an example. Specifically:

[0067] S100: Obtain device identifiers for multiple electrical devices.

[0068] In this context, "electrical equipment" refers to various devices that utilize electrical energy for operation; in this application, "electrical equipment" refers to devices whose carbon data needs to be transmitted to the blockchain. "Equipment identifier" refers to a unique identifier for the electrical equipment.

[0069] Specifically, the user selects the device identifiers of multiple electrical devices to be transmitted for carbon data on the carbon data processing interface of the terminal and triggers the carbon data uplink control; the terminal responds to the trigger request of the carbon data uplink control, generates a carbon data transmission request, which carries the device identifiers of multiple electrical devices, and sends the carbon data transmission request to the edge server; the edge server obtains the device identifiers of multiple electrical devices.

[0070] S200, for each device identifier, calls the driver module that matches the device identifier, and uses the protocol in the driver module to detect the carbon data of the electrical equipment that matches the device identifier.

[0071] The driver module encapsulates the protocol associated with the device identifier. This means it introduces a "protocol parsing plug-in mechanism," with each protocol corresponding to a separate parsing driver. This allows the driver module to support multi-protocol acquisition from mainstream electrical terminals, including but not limited to RS485 (Recommended Standard 485, a serial communication physical interface standard), DLT645 (DL / T 645 communication protocol), Modbus (Modbus Protocol, an industrial communication protocol), CAN (Controller Area Network), and LoRa (Long Range Radio, LoRa wireless communication technology). Furthermore, the driver module supports flexible configuration via hot-loading. Carbon data refers to quantitative information related to the energy consumption and carbon emissions of electrical equipment.

[0072] Specifically, this application requires the transmission of carbon data from multiple electrical devices. As a result, there are many types of terminal devices and complex communication protocols, including but not limited to RS485, Modbus, DLT645, and MQTT (Message Queuing Telemetry Transport). This results in significant differences in the structure, frequency, and semantics of the data on the electrical device side, making unified collection and fusion difficult.

[0073] Therefore, this application adopts a modular driver mechanism for decoupling design to address the diversity of terminal protocols. That is, each protocol (such as Modbus, DLT645, MQTT, etc.) is encapsulated as an independent driver module, which contains command format, data frame parsing logic, exception handling strategy, etc.

[0074] The system has a unified driver scheduling interface. During startup or operation, the corresponding driver module is loaded according to the terminal identifier. The protocol in the driver module is used to detect the energy consumption and carbon emission related quantitative information of the electrical equipment that matches the device identifier, so as to obtain the carbon data of the electrical equipment. Furthermore, the driver module supports hot-swappable loading, that is, a certain protocol driver module can be dynamically enabled, replaced or uninstalled without interrupting the main process of the system to adapt to new equipment or upgrade scenarios.

[0075] In addition, the call chain of the driver module is uniformly managed by the edge nodes to ensure a clear data acquisition and scheduling process and a unified data acquisition structure.

[0076] The above mechanism enables "plug-and-play drivers and flexible protocol adaptation", which significantly reduces system maintenance costs and improves compatibility with heterogeneous devices.

[0077] S300 performs semantic extraction on the carbon data of multiple electrical devices to obtain carbon semantic data of multiple electrical devices.

[0078] Semantic extraction refers to the process of automatically identifying and extracting meaningful semantic information from unstructured or semi-structured data (such as text, images, and speech) and transforming it into structured data. Its core goal is to understand the deeper meaning of the data (i.e., "semantics"), rather than remaining at the surface level of syntax or symbols. Carbon semantic data refers to the structured description of the meaning, associations, and constraints of carbon data.

[0079] Specifically, due to the significant differences in structure, frequency, and semantics of data from electrical equipment, unified collection and fusion are difficult. Therefore, semantic extraction can be performed on the collected carbon data of electrical equipment to obtain carbon semantic data for each electrical equipment.

[0080] Furthermore, semantic extraction of the collected carbon data from electrical equipment involves abstracting the collected carbon data into a unified "carbon data standard object model." This "carbon data standard object model" is an abstract structure that unifies the semantics of data from different terminals. An example of a unified carbon semantic data field is as follows:

[0081] {Voltage: xxx, Current: xxx, Active power: xxx, Regional carbon factor: xxx, Power factor: xxx, Frequency: xxx, Terminal number: device_id_xx, Data collection timestamp: timestamp, Region code: region_code}.

[0082] In other words, carbon data from multiple electrical devices are semantically extracted using a semantically unified abstract structure, and the resulting carbon semantic data will be generated according to this semantically unified abstract structure.

[0083] S400 fuses carbon semantic data from multiple electrical devices to obtain fused carbon data.

[0084] Specifically, the edge server is configured with edge computing capabilities to periodically aggregate carbon data from multiple electrical devices, detect the carbon semantic data corresponding to the carbon data of each electrical device, and then fuse the carbon semantic data of multiple electrical devices to obtain fused carbon data.

[0085] One method for fusing carbon semantic data from multiple electrical devices is direct fusion, which involves adding the carbon semantic data from multiple electrical devices together; another method is weighted fusion, which involves obtaining the weight coefficient corresponding to each electrical device and weighting the carbon semantic data from multiple electrical devices together based on the weight coefficients corresponding to the multiple electrical devices.

[0086] The S500 will integrate carbon data transmission to the blockchain.

[0087] Specifically, the final step is to integrate the carbon data and transmit it to the blockchain to store the carbon data of multiple electrical devices on the blockchain.

[0088] Furthermore, because blockchain primarily focuses on the immutability of data after it is uploaded to the blockchain, it lacks security guarantees for the off-chain to on-chain transmission process. Coupled with the complexity of the data collection chain on the power equipment side and frequent communication relays, if the front-end power equipment is not effectively protected, the carbon data from the equipment is vulnerable to attacks such as tampering by intermediate network nodes, cache contamination, and forged uploads before being stored on the blockchain. This can lead to problems such as carbon data being tampered with, forged, or delayed on-chain, challenging the credibility of on-chain data and creating a systemic gap where "on-chain is trustworthy, but off-chain is untrustworthy." Therefore, when transmitting fused carbon data to the blockchain, it is also necessary to encrypt the fused carbon data to improve its tamper-proof capabilities.

[0089] In one embodiment, this application also introduces a cache isolation mechanism to separate the carbon data acquisition cache from the transmission buffer, that is, to decouple the step of detecting carbon data of electrical equipment from the step of transmitting the fused carbon data to the blockchain, so as to avoid the distortion of the current calculation due to residual data from the previous calculation.

[0090] In the aforementioned carbon data transmission methods, the communication protocols of current electrical devices are complex and the number of devices is large, resulting in low efficiency in carbon data collection and affecting the carbon data transmission process. Therefore, this application provides an efficient carbon data transmission method. Throughout the process, the protocol is encapsulated in the driver module, decoupling the protocol protocols of each electrical device. That is, each driver module matching the device identifier encapsulates the protocol protocol matching the device identifier. Compared with the complex protocol protocols in the prior art that support the collection of carbon data from all electrical devices, the protocol protocol matching the device identifier in this application is simpler. Therefore, it can improve the efficiency of detecting carbon data from electrical devices with matching device identifiers, further improving the efficiency of carbon data transmission. At the same time, after detecting carbon data from multiple electrical devices with matching device identifiers, key semantic information in the carbon data of the electrical devices can be extracted, interference from irrelevant data can be removed, the amount of carbon data can be reduced, and the fused carbon data can be efficiently transmitted to the blockchain.

[0091] In one exemplary embodiment, carbon semantic data from multiple electrical devices are fused to obtain fused carbon data, including:

[0092] The historical communication status of multiple electrical devices is detected; based on the historical communication status of multiple electrical devices, the carbon semantic data of multiple electrical devices are fused to obtain fused carbon data.

[0093] Historical communication status typically refers to the operating status, interaction process, and related data records of electrical equipment during a certain period of time in the past.

[0094] Specifically, in the process of carbon data fusion of multiple user devices, the impact of different device accuracy, network quality or physical location on data reliability is considered, and a weight correction mechanism is introduced. That is, instead of simply adding and fusing the carbon semantic data of multiple devices, this embodiment also detects the historical communication status of each device in the historical time period to determine the device's own communication capability. Then, based on the device's own communication capability, the fusion weight of each device is corrected. Finally, based on the corrected fusion weight, the carbon semantic data of multiple devices are weighted and fused to obtain fused carbon data.

[0095] Furthermore, information such as the establishment and disconnection of communication connections, data transmission quality (e.g., bandwidth, latency, packet loss rate), signal strength, device operating mode (e.g., standby, transmission, fault), and user interaction records during the historical process of transmitting carbon data to the blockchain can be obtained to detect the historical communication status of electrical devices. Then, based on the historical communication status of multiple electrical devices, the carbon semantic data of multiple electrical devices can be fused to obtain fused carbon data.

[0096] Furthermore, the historical communication status of electrical devices can be quantified using status levels, which can include quantification levels such as good, relatively good, average, poor, and very poor. Based on the different quantification levels of each electrical device, different fusion weights are assigned to each device, with each quantification level corresponding to a fusion weight, to perform weighted fusion of carbon semantic data from multiple electrical devices.

[0097] In this embodiment, by detecting the historical communication status of multiple electrical devices, the carbon semantic data of multiple electrical devices in the current time period can be accurately fused by combining the communication status experience of electrical devices in the historical time period.

[0098] In one exemplary embodiment, detecting the historical communication status of multiple electrical devices includes:

[0099] The system detects the historical transmission success rate and historical data fluctuation information of multiple electrical devices. The historical transmission success rate represents the proportion of successfully transmitted data to the blockchain within a historical time period out of all pending communication data. The historical data fluctuation information represents the data fluctuation amplitude and frequency of pending communication data of electrical devices during transmission within a historical time period. Based on the historical transmission success rate and historical data fluctuation information of each electrical device, the system detects the historical communication status of the corresponding electrical device.

[0100] Among them, the historical transmission success rate measures the proportion of successful communication within a historical period (such as the ratio of successful requests / connections to the total number of requests, which is generally used to characterize the proportion of successfully transmitted data to the blockchain within a historical period to all pending communication data; data fluctuation information describes the instability of data during transmission, processing or storage (such as delay fluctuations, abnormal value jumps), which is generally used to characterize the continuity characteristics such as the amplitude and frequency of data fluctuations of pending communication data of electrical equipment during transmission within a historical period.

[0101] Specifically, the historical transmission success rate and historical data fluctuation information of multiple electrical devices are detected. The historical transmission success rate essentially reflects the reliability of the device's transmission, while the historical data fluctuation information reflects its stability. Therefore, by using the historical transmission success rate and historical data fluctuation information of each electrical device, the reliability and stability of transmitting carbon data from the devices to the blockchain can be detected. Based on the reliability and stability of the carbon data transmission from the devices to the blockchain, the historical communication status of the devices is determined. Based on the historical communication status of the devices, the fusion weight of each device is adjusted; for example, if the data packet loss rate is high within the last 10 minutes, the weight is lowered.

[0102] Furthermore, successfully transmitted data to the blockchain typically refers to data that has arrived completely and accurately at the target end, and the receiver sends an ACK (Acknowledge character) response to confirm its accuracy. If a data packet does not receive an ACK within a specified time, it is considered a failure. For example, if a device initiates 1000 data transmissions in the past 24 hours, with 950 successes and 50 failures, then the historical transmission success rate = 950 / 1000 × 100% = 95%.

[0103] Historical data fluctuations include various types, such as:

[0104] 1. Abnormal fluctuations: Data points deviate significantly from the normal range (such as sudden surges or drops).

[0105] 2. Trend fluctuations: Data continues to rise or fall over time (such as seasonal growth).

[0106] 3. Periodic fluctuations: The data shows regular repetition (such as daily peaks and weekly traffic fluctuations).

[0107] When obtaining the fluctuation type for each user device, the data fluctuation amplitude of the user device should be obtained for each fluctuation type. For example, the amplitude of data deviation from the normal range when obtaining abnormal fluctuation type, or the amplitude of data continuous rise or fall over time when obtaining trend fluctuation type.

[0108] By dividing the historical time period into multiple historical sub-time periods, the frequency of data fluctuations within the historical time period can be detected based on the number of fluctuations corresponding to the different types of abnormal fluctuations. For example, when multiple abnormal fluctuations occur within the historical time period, the frequency of data fluctuations of the user device can be determined based on the number of fluctuations corresponding to the types of abnormal fluctuations.

[0109] Then, by combining the historical transmission success rate and historical data fluctuation information of the user equipment, the historical communication status of the corresponding power equipment is detected. For example, when the historical data fluctuation information indicates that the user equipment has frequent abnormal fluctuations or the historical transmission success rate is lower than the preset range threshold, the historical communication status of the user equipment will be quantified as poor; when the historical data fluctuation information indicates that the user equipment has frequent abnormal fluctuations and the historical transmission success rate is lower than the preset range threshold, the historical communication status of the user equipment will be quantified as poor.

[0110] In the above embodiments, the historical transmission success rate and historical data fluctuation information of each of the multiple electrical devices are detected to detect the reliability and stability of the carbon data of the electrical devices to the blockchain. In this way, the historical communication status of the electrical devices can be accurately determined, thereby improving the accuracy of fusing the carbon semantic data of multiple electrical devices.

[0111] In one exemplary embodiment, such as Figure 3 As shown, S400 includes:

[0112] S410 extracts the power consumption information, regional carbon factor information, and collection timestamp information of each electrical device from carbon semantic data.

[0113] S420 generates carbon data of electrical equipment within a target time window based on electricity consumption information, regional carbon factor information, and data collection timestamp information.

[0114] S430 fuses the carbon data of all electrical devices within the target time window to obtain fused carbon data.

[0115] Electricity consumption refers to the total amount of electrical energy consumed by electrical equipment (such as household appliances, industrial machinery, and vehicles) within a certain period of time, and is a core indicator for measuring the scale and demand of electricity use. Regional carbon factor information is a key indicator for measuring the carbon dioxide emissions generated by a unit of economic activity or resource consumption within a specific region, and is used to assess the region's carbon emission intensity, low-carbon development level, and effectiveness in addressing climate change.

[0116] Specifically, the collection timestamp information of electrical devices is extracted from carbon semantic data. Carbon semantic data obtained from the same collection timestamp of multiple electrical devices will enter the same time window processing pool after periodic collection.

[0117] If we define the same time window processing pool as the target time window, then within that target time window, for each electrical device, since the carbon semantic data includes fields such as voltage, current, active power, regional carbon factor, power factor, frequency, terminal number, collection timestamp, and region code, we can extract the power consumption information and regional carbon factor information of the electrical device from the carbon semantic data. Based on this information, we can then generate the carbon data for the electrical device within the target time window. Finally, we perform weighted fusion of the carbon data for all electrical devices within the target time window to obtain fused carbon data.

[0118] Furthermore, electricity consumption information can be deduced from fields such as voltage, current, and sampling period in the carbon semantic data, with the deduction process being "voltage × current × sampling period," or it can be directly obtained from the active power field. Regional carbon factor information is generally dynamically loaded into the carbon data based on the equipment deployment location for subsequent acquisition.

[0119] For example, the fused carbon data = Σki (electricity consumption information of device i × regional carbon factor information), where ki is the fusion weight of device i, and the electricity consumption information of device i = voltage information of device i × current information of device i × sampling period of device i.

[0120] In one embodiment, to improve the stability and anti-interference capability of carbon data fusion results, this application, based on the aforementioned carbon data fusion, also introduces a sliding window-based low-pass filtering algorithm and an outlier removal mechanism: A window width N (e.g., 3-5) is set, and the most recent N sets of data from the same source are taken each time, and average or median filtering is performed to effectively smooth short-term fluctuations, thus obtaining the carbon data of electrical equipment within the target time window; for measurement values ​​exhibiting instantaneous spikes, the system sets an "amplitude threshold" (e.g., data fluctuation exceeding 30% within 10 seconds), which is determined as an outlier and automatically removed; for data streams with continuous jitter, a trend judgment algorithm (e.g., linear fitting residual analysis) is used to determine whether it is due to equipment jitter or signal interference, triggering a weighting process for the fusion stage of that user's equipment. The combined use of the above filtering and correction techniques with the data weighting mechanism significantly improves data quality while ensuring near real-time performance.

[0121] In one embodiment, this application can also aggregate fused carbon data within multiple target time windows to obtain fused carbon data over a larger time range.

[0122] In the above embodiments, by extracting the electricity consumption information, regional carbon factor information and collection timestamp information of the electrical devices from the carbon semantic data, the fused carbon data of all electrical devices can be accurately generated.

[0123] In one exemplary embodiment, transmitting fused carbon data to a blockchain includes:

[0124] The process involves detecting the digest information of the fused carbon data; using a pre-loaded private key to digitally sign the fused carbon data, obtaining the signature information of the fused carbon data; combining the digest information, signature information, and fused carbon data; and transmitting the combined fused carbon data to the blockchain.

[0125] In cryptography, a message digest, also known as a hash value or message digest, is a fixed-length binary string generated by calculating the hash of original data of arbitrary length using a hash function. A private key is a crucial parameter in asymmetric encryption algorithms; it is a secret string kept by the user and appears in pair with the publicly disclosed public key. A digital signature is a cryptographic technique used to verify the authenticity and integrity of a message.

[0126] Specifically, a hash algorithm, such as SHA256 (Secure Hash Algorithm-256) or the national cryptographic algorithm SM3, is used to obtain the digest information of the fused carbon data. Then, a pre-loaded private key is used to digitally sign the fused carbon data to obtain the signature information of the fused carbon data, so as to ensure the authenticity of the source. Finally, the digest information, signature information and fused carbon data are combined to form a set of verifiable and trusted data structures, and the combined fused carbon data is transmitted to the blockchain.

[0127] Furthermore, this application also maintains a near real-time connection with the blockchain access node via WebSocket, MQTT, or 4G / Ethernet links; each signed carbon emission data is automatically written to the blockchain by calling the uplink interface, and smart contract records are generated in the blockchain. The smart contract records key fields such as the original data packet, hash digest, electrical equipment identifier, and timestamp. In addition, after the carbon data is integrated and written to the blockchain, a unique on-chain index number, such as TxID (transaction ID), is generated to support subsequent query and verification.

[0128] In the above embodiments, combining the summary information, signature information, and fused carbon data, and transmitting the combined fused carbon data to the blockchain, can encrypt the transmission process of the fused carbon data, reducing the possibility of the fused carbon data being tampered with during transmission.

[0129] In one exemplary embodiment, transmitting the combined fused carbon data to a blockchain includes:

[0130] The gateway on the blockchain side extracts the digest information, signature information and fused carbon data from the combined fused carbon data, and controls the gateway to perform consistency verification on the digest information and signature information respectively; if the verification results show that the digest information is consistent with the standard digest information pre-stored by the gateway and the signature information is consistent with the standard digest information pre-stored by the gateway, the fused carbon data is written into the blockchain.

[0131] Specifically, before the combined fused carbon data is written to the blockchain, the gateway on the blockchain side can be controlled to extract the digest information, signature information and fused carbon data from the combined fused carbon data, so as to perform consistency verification on the digest information and signature information respectively. That is, it verifies whether the digest information is consistent with the standard digest information pre-stored by the gateway, and verifies whether the signature information is consistent with the standard digest information pre-stored by the gateway. If they are both consistent, the combined fused carbon data is transmitted to the blockchain.

[0132] In this embodiment, by performing consistency checks on the digest information and signature information separately before writing them into the blockchain, it is possible to verify whether data tampering or other issues occur during the transmission of the combined fused carbon data, thereby improving the security of carbon data transmission.

[0133] In one embodiment, this application also supports a two-way verification mechanism between on-chain data and off-chain cached data, wherein the two-way verification mechanism includes two dimensions:

[0134] On-chain to off-chain verification: Actively request edge nodes to compare the original data cached locally with the signature using the data index (such as user device identifier + timestamp + hash digest) stored in the on-chain smart contract.

[0135] Off-chain to on-chain verification: Edge nodes periodically backtrack successful upload records within the last M minutes, comparing them with on-chain receipt records to check for existence and tampering (by comparing hash values, signature field consistency, etc.). Once a discrepancy is detected, an alarm mechanism is triggered and the abnormal data isolation process begins.

[0136] Furthermore, this application also provides a "data path tracing proof" function: it can trace back the terminal number, protocol, processing node, signer and other metadata of each piece of on-chain data; in abnormal scenarios (such as upload failure, inconsistent signature), the system automatically triggers log recording and retransmission strategies; the entire process supports the supervision node to audit the entire chain process of "data collection → fusion → signing → on-chain".

[0137] This application proposes a carbon data transmission method that addresses the current challenges of diverse electrical devices, complex communication protocols, and insufficient data reliability. It constructs an off-chain to on-chain data protection channel integrating protocol decoupling, edge computing, data signing, and trusted on-chain data transmission. This ensures the uniformity, low latency, and immutability of carbon data throughout the entire process from collection to on-chain transmission. Figure 4 As shown, the carbon data transmission method will be described in detail below in several modules:

[0138] 1. Heterogeneous device protocol adaptation and data acquisition module:

[0139] The process involves initiating carbon data collection from multiple electrical devices. Specifically, it involves acquiring device identifiers for each device. For each device identifier, the process calls the driver module that matches the device identifier. The driver module then uses the protocol protocol associated with the device identifier to parse the carbon data of the device. The driver module encapsulates the protocol protocol associated with the device identifier. Semantic extraction is performed on the carbon data from multiple devices, and the data is uniformly mapped to a standardized "carbon data standard object model." The "carbon data standard object model" corresponding to each device is used as the carbon semantic data for each device.

[0140] 2. Edge-side near real-time fusion processing module:

[0141] The system detects the historical transmission success rate and historical data fluctuation information of multiple electrical devices. The historical transmission success rate represents the proportion of successfully transmitted data to the blockchain within a historical time period out of all pending communication data. The historical data fluctuation information represents the data fluctuation amplitude and frequency of pending communication data of electrical devices during transmission within a historical time period. Based on the historical transmission success rate and historical data fluctuation information of each electrical device, the system detects the historical communication status of the corresponding electrical device.

[0142] Based on the historical communication status of multiple electrical devices, each device is assigned a fusion weight. Then, based on the fusion weight of each device, the carbon semantic data of the multiple devices are fused to obtain fused carbon data.

[0143] The process involves fusing carbon semantic data from multiple electrical devices to obtain fused carbon data. This includes: for each electrical device, extracting its electricity consumption information, regional carbon factor information, and collection timestamp information from the carbon semantic data; and generating carbon data for the electrical device within a target time window based on the electricity consumption information, regional carbon factor information, and collection timestamp information; and fusing the carbon data of all electrical devices within the target time window to obtain fused carbon data.

[0144] Furthermore, during the fusion of carbon semantic data from multiple electrical devices, time window aggregation and noise reduction processing can also be performed, as described in the above embodiments, and will not be repeated here.

[0145] 3. Data encryption and anti-tampering verification module:

[0146] The process involves detecting the digest information of the fused carbon data; using a pre-loaded private key to digitally sign the fused carbon data, obtaining the signature information of the fused carbon data; combining the digest information, signature information, and fused carbon data; and transmitting the combined fused carbon data to the blockchain.

[0147] Before the combined carbon data is uploaded to the blockchain, the gateway on the blockchain side extracts the digest information, signature information and combined carbon data from the combined carbon data, and controls the gateway to perform consistency verification on the digest information and signature information respectively; if the verification results show that the digest information is consistent with the standard digest information pre-stored by the gateway and the signature information is consistent with the standard digest information pre-stored by the gateway, the combined carbon data is written into the blockchain.

[0148] 4. Blockchain near real-time synchronization and recording module:

[0149] The system maintains a near real-time connection with the blockchain access node via WebSocket, MQTT, or 4G (Fourth-Generation) / Ethernet links; each signed carbon data is automatically written to the blockchain by calling the on-chain interface, and the smart contract records key fields such as the original data packet, hash digest, terminal ID, and timestamp; after the data is written to the chain, a unique on-chain index number is generated to support subsequent query and verification.

[0150] 5. Data verification and channel integrity assurance module:

[0151] It supports a two-way verification mechanism between on-chain data and off-chain cached data, which includes two dimensions; it provides a "data path tracing proof" function: it can trace back the terminal number, protocol, processing node, signer and other metadata of each piece of on-chain data; in abnormal scenarios (such as upload failure, inconsistent signature), the system automatically triggers log recording and retransmission strategies; the entire process supports the supervision node to audit the entire chain process of "data collection → fusion → signing → on-chain".

[0152] Based on the above modules, it can be seen that this application, by constructing an off-chain channel mechanism with protocol adaptation, integrated computing, secure signature, and trusted on-chain capabilities, successfully solves the technical bottlenecks of difficulty in unifying carbon emission data collection, difficulty in ensuring tamper prevention, and difficulty in improving on-chain efficiency in heterogeneous terminal environments, and has the following significant technical effects:

[0153] 1. Streamline the data acquisition process for heterogeneous terminals: Through protocol decoupling and standard data model mapping mechanisms, unified acquisition and processing of mainstream protocol devices such as RS485, DLT645, and Modbus can be achieved, avoiding the problems of fragmented access of multiple terminals and cumbersome manual configuration in existing systems.

[0154] 2. Improve carbon data fusion efficiency and real-time performance: Data fusion, filtering correction and verification are completed in real time through edge computing devices, achieving "minute-level" or "second-level" synchronization capability from terminal collection to fusion and on-chain, which is significantly better than the traditional "hour-level" centralized collection solution.

[0155] 3. Ensure data source security and tamper resistance: Adopt off-chain digital signature and data digest mechanisms to ensure that each piece of data is bound to the device identity and collection time before being uploaded. Any off-chain attacks or man-in-the-middle tampering will be detected immediately, strengthening the credibility of the carbon data ownership confirmation process.

[0156] 4. Form a closed-loop system for the trusted collection of carbon emission data: Through on-chain evidence storage and off-chain verification mechanisms, a complete process from user devices → edge → blockchain is constructed, supporting subsequent data to be traceable, verifiable, and auditable, providing a trust foundation for carbon asset registration, green electricity verification, and other activities.

[0157] 5. Possesses engineering feasibility and platform adaptability: This solution is adaptable to various deployment environments. It can be used for smart terminal integration under the Southern Power Grid and the power Internet of Things system in industrial parks, and can also be extended to carbon emission online monitoring platforms and the integrated construction of "carbon-electricity-data" in industrial parks.

[0158] In summary, this application provides key channel support for building a reliable underlying carbon emission perception system, fills the gap between "on-chain reliability" and "terminal reliability", and is an important underlying foundation for the compliant flow of carbon emission data, reliable carbon asset ownership confirmation, and reliable governance of the carbon market.

[0159] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0160] Based on the same inventive concept, this application also provides a carbon data transmission device for implementing the carbon data transmission method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more carbon data transmission device embodiments provided below can be found in the limitations of the carbon data transmission method described above, and will not be repeated here.

[0161] In one exemplary embodiment, such as Figure 5 As shown, a carbon data transmission device is provided, comprising: an identifier acquisition module 100, a protocol parsing module 200, a semantic extraction module 300, a data fusion module 400, and a data transmission module 500, wherein:

[0162] The identifier acquisition module 100 is used to acquire the device identifiers of multiple electrical devices.

[0163] The protocol parsing module 200 is used to call the driver module that matches the device identifier for each device identifier, so as to use the protocol in the driver module to detect the carbon data of the electrical equipment that matches the device identifier; wherein, the driver module encapsulates the protocol associated with the device identifier;

[0164] The semantic extraction module 300 is used to extract the carbon data of multiple electrical devices to obtain the carbon semantic data of multiple electrical devices.

[0165] The data fusion module 400 is used to fuse carbon semantic data from multiple electrical devices to obtain fused carbon data.

[0166] The data transmission module 500 is used to transmit fused carbon data to the blockchain.

[0167] In one embodiment, the data fusion module 400 is further configured to detect the historical communication status of multiple electrical devices; and based on the historical communication status of the multiple electrical devices, to fuse the carbon semantic data of the multiple electrical devices to obtain fused carbon data.

[0168] In one embodiment, the data fusion module 400 is further used to detect the historical transmission success rate and historical data fluctuation information of each of the multiple electrical devices. The historical transmission success rate represents the proportion of successfully transmitted data to the blockchain within a historical time period to all pending communication data. The historical data fluctuation information represents the data fluctuation amplitude and data fluctuation frequency of the pending communication data of the electrical devices during transmission within a historical time period. Based on the historical transmission success rate and historical data fluctuation information of each electrical device, the historical communication status of the corresponding electrical device is detected.

[0169] In one embodiment, the data fusion module 400 is further configured to extract, for each electrical device, electricity consumption information, regional carbon factor information and collection timestamp information from carbon semantic data, and generate electrical device carbon data within a target time window based on the electricity consumption information, regional carbon factor information and collection timestamp information; and fuse the electrical device carbon data of all electrical devices within the target time window to obtain fused carbon data.

[0170] In one embodiment, the data transmission module 500 is further configured to detect the digest information of the fused carbon data; digitally sign the fused carbon data using a pre-loaded private key to obtain the signature information of the fused carbon data; combine the digest information, the signature information, and the fused carbon data; and transmit the combined fused carbon data to the blockchain.

[0171] In one embodiment, the data transmission module 500 is further configured to control the gateway on the blockchain side to extract the digest information, signature information and fused carbon data from the combined fused carbon data, and control the gateway to perform consistency verification on the digest information and signature information respectively; if the verification results indicate that the digest information is consistent with the standard digest information pre-stored by the gateway and the signature information is consistent with the standard digest information pre-stored by the gateway, the fused carbon data is written into the blockchain.

[0172] Each module in the aforementioned carbon data transmission device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0173] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data such as device identifiers for multiple electrical devices. The I / O interfaces are used for information exchange between the processor and external electrical devices. The communication interface is used for communication with external terminals via a network connection. When executed by the processor, the computer program implements a carbon data transmission method.

[0174] Those skilled in the art will understand that Figure 6 The structure shown is a block diagram of a partial structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0175] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0176] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0177] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0178] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0179] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0180] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A carbon data transmission method, characterized by, The method comprises: obtaining device identifiers of a plurality of power-using devices; for each device identifier, calling a driving module matched with the device identifier to detect carbon data of the power-using device matched with the device identifier by using a protocol in the driving module, wherein the driving module encapsulates a protocol associated with the device identifier; performing semantic extraction on carbon data of the plurality of power-using devices to obtain carbon semantic data of the plurality of power-using devices, wherein the semantic extraction on the carbon data of the plurality of power-using devices is performed in a semantic-unified abstract structure, and the obtained carbon semantic data is generated according to the semantic-unified abstract structure; fusing the carbon semantic data of the plurality of power-using devices to obtain fused carbon data, wherein the fusing of the carbon semantic data of the plurality of power-using devices to obtain the fused carbon data comprises: detecting historical communication states of the plurality of power-using devices, wherein the historical communication states of the plurality of power-using devices are used to represent stability of reliability of the power-using devices in communication; correcting a fusion weight of each power-using device based on the historical communication states of the plurality of power-using devices, and performing weighted fusion on the carbon semantic data of the plurality of power-using devices based on the corrected fusion weight of each power-using device to obtain the fused carbon data; transmitting the fused carbon data to a blockchain.

2. The method of claim 1, wherein, The detection of the historical communication states of the plurality of power-using devices comprises: detecting historical transmission success rates and historical data fluctuation information of the plurality of power-using devices respectively, wherein the historical transmission success rate represents a proportion of transmission success data that has been transmitted to the blockchain to all data to be communicated in a historical time period, and the historical data fluctuation information represents a data fluctuation amplitude and a data fluctuation frequency of the data to be communicated of the power-using device in transmission in the historical time period; detecting a historical communication state of each power-using device based on the historical transmission success rate and the historical data fluctuation information of the power-using device.

3. The method of claim 1, wherein, The fusing of the carbon semantic data of the plurality of power-using devices to obtain the fused carbon data comprises: for each power-using device, extracting power consumption information, regional carbon factor information, and collection timestamp information of the power-using device from the carbon semantic data, and generating power-using device carbon data in a target time window based on the power consumption information, the regional carbon factor information, and the collection timestamp information; fusing power-using device carbon data of all the power-using devices in the target time window to obtain the fused carbon data.

4. The method of claim 1, wherein, The transmission of the fused carbon data to the blockchain comprises: detecting digest information of the fused carbon data; performing digital signature on the fused carbon data by using a preloaded private key to obtain signature information of the fused carbon data; combining the digest information, the signature information, and the fused carbon data, and transmitting the combined fused carbon data to the blockchain.

5. The method of claim 4, wherein, The transmission of the combined fused carbon data to the blockchain comprises: The gateway on the blockchain side extracts the summary information, the signature information and the fused carbon data in the combined fused carbon data, and controls the gateway to perform consistency verification on the summary information and the signature information respectively; In a case where the verification result indicates that the summary information is consistent with the standard summary information pre-stored by the gateway and the signature information is consistent with the standard signature information pre-stored by the gateway, the fused carbon data is written into the blockchain.

6. A carbon data transmission device, characterized by, The apparatus comprises: An identification acquisition module configured to acquire device identifications of a plurality of power-consuming devices; A protocol analysis module configured to, for each of the device identifications, call a driving module matched with the device identification, and detect carbon data of the power-consuming device matched with the device identification by using a protocol in the driving module, wherein the driving module encapsulates a protocol associated with the device identification; A semantic extraction module configured to perform semantic extraction on carbon data of the plurality of power-consuming devices to obtain carbon semantic data of the plurality of power-consuming devices, wherein the semantic extraction on the carbon data of the plurality of power-consuming devices is performed in a semantic-unified abstract structure, and the obtained carbon semantic data is generated according to the semantic-unified abstract structure; A data fusion module configured to fuse the carbon semantic data of the plurality of power-consuming devices to obtain fused carbon data, wherein the fusion of the carbon semantic data of the plurality of power-consuming devices to obtain the fused carbon data comprises detecting historical communication states of the plurality of power-consuming devices, wherein the historical communication states of the plurality of power-consuming devices are used to represent stability of reliability of the power-consuming devices, correcting a fusion weight of each of the power-consuming devices based on the historical communication states of the plurality of power-consuming devices, and performing weighted fusion on the carbon semantic data of the plurality of power-consuming devices based on the corrected fusion weight of each of the power-consuming devices to obtain the fused carbon data; A data transmission module configured to transmit the fused carbon data to a blockchain.

7. The apparatus of claim 6, wherein, The data fusion module is further configured to detect historical transmission success rates and historical data fluctuation information of the plurality of power-consuming devices, wherein the historical transmission success rate represents a proportion of transmission success data that has been transmitted to the blockchain to all to-be-communicated data in a historical time period, and the historical data fluctuation information represents a data fluctuation amplitude and a data fluctuation frequency of to-be-communicated data of the power-consuming devices in transmission in the historical time period; and the historical communication state of each of the power-consuming devices is detected based on the historical transmission success rate and the historical data fluctuation information of the power-consuming device.

8. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, The processor, when executing the computer program, implements the steps of the method of any one of claims 1 to 5.

9. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program, when executed by the processor, implements the steps of the method of any one of claims 1 to 5.

10. A computer program product comprising a computer program, characterized in that, The computer program, when executed by the processor, implements the steps of the method of any one of claims 1 to 5.

Images