Blockchain-based carbon footprint monitoring and assessment method and system

Abstract

The application discloses a carbon footprint monitoring and evaluation method and system based on a block chain, relates to the technical field of industrial carbon footprint monitoring and evaluation, and forms an occupation relationship record among order identification, shared resource identification and occupation events by matching the occupation events in the order process event chain with the resource occupation time window in the shared process resource account object, generates a collection locking key based on the accounting boundary identification, the shared resource identification, the resource occupation time window, the resource consumption summary identification and the allocation rule version, so that the shared resource consumption is first determined to hit on the chain before entering the order-level carbon load allocation record; a repeated collection prompt is generated when the existing collection locking key is hit, and an order-level carbon load allocation record is generated when the existing collection locking key is not hit, so that the order events, resource consumption, allocation basis and on-chain credentials in the outsourcing shared process form a verifiable association.

Description

Technical Field

[0001] This invention relates to the field of industrial carbon footprint monitoring and assessment technology, and in particular to a blockchain-based carbon footprint monitoring and assessment method and system. Background Technology

[0002] Outsourced surface treatment services include electroplating, heat treatment, spraying, anodizing, and other processing types. Clients typically deliver parts in small batches with a variety of product types, while the processing providers usually organize continuous production using bath solutions, furnaces, racks, rollers, drying lines, pure water systems, compressed air systems, and wastewater treatment systems. During the same production period, multiple orders may simultaneously or alternately occupy the same shared process resources, resulting in different data granularities between order flow records and resource consumption records.

[0003] Existing carbon footprint monitoring and assessment methods typically calculate carbon emissions based on activity data and emission factors. They can also collect energy consumption, batch, and process data through electricity meters, gas meters, temperature control equipment, rectifiers, MES, ERP systems, barcodes, or RFID to generate carbon footprint results for products, batches, or orders. To achieve cross-entity traceability, some systems also write collected records, calculation results, audit conclusions, or voucher summaries to the blockchain.

[0004] In high-mixed-flow, small-batch outsourced surface treatment scenarios, resource consumption from bath insulation, rectifier output, furnace heating and insulation, rack loading, drum operation, drying waiting, pure water preparation, compressed air supply, and wastewater treatment often corresponds to multiple order occupancy windows. After events such as order insertion, furnace merging, mixed loading, waiting, rework, and scrapping occur, the actual occupancy status of orders can change. If resource consumption is allocated solely based on output, weight, area, batch size, or cycle average, the attribution of shared resource consumption can easily change with the combination of orders within the same time period. Furthermore, if only equipment-level resource consumption and the final carbon footprint results are recorded, there is a lack of verifiable correlation between order process events, resource occupancy windows, allocation basis, and voucher status.

[0005] Furthermore, outsourced processing often involves sensitive production information such as bath formulations, current profiles, loading rates, production schedules, and other customer orders. When verifying order-level carbon footprint vouchers, the client needs to confirm the correspondence between shared resource consumption and orders, as well as the aggregation status of the same resource consumption within the accounting boundary. Meanwhile, the processor, when providing verification evidence, needs to control the scope of disclosure of sensitive production details. This makes it difficult for order-level carbon footprint vouchers to simultaneously meet the requirements of verifying shared resource allocation, identifying duplicate aggregations, and tracing cross-entity evidence.

[0006] Therefore, the order-level carbon footprint monitoring and assessment of shared processes in outsourced surface treatment urgently needs to address the technical challenge of establishing verifiable correlations between order process events, shared resource consumption, allocation criteria, and on-chain credentials. Summary of the Invention

[0007] This application provides a blockchain-based carbon footprint monitoring and assessment method and system, which solves the problem that it is difficult to verify and correlate order events, resource consumption, allocation basis and on-chain credentials in outsourced shared processes.

[0008] In a first aspect, embodiments of the present invention provide a blockchain-based carbon footprint monitoring and assessment method, which includes:

[0009] Receive outsourced surface treatment order data containing order identifiers and accounting boundary identifiers, and generate order carbon footprint vouchers;

[0010] Receive process event data generated by the processing system and generate an order process event chain according to the same order identifier and event time;

[0011] For shared process resources occupied by multiple orders, a shared process resource ledger object is generated. The shared process resources include at least one of the following: tank liquid, furnace, hanger, drum, drying line, pure water system, air compressor system and wastewater treatment system. The shared process resource ledger object records the shared resource identifier, resource type, resource occupation time window, resource consumption summary and resource consumption summary identifier.

[0012] When the occupancy event in the order process event chain falls within the resource occupancy time window, the order identifier, shared resource identifier, and occupancy event are written into the occupancy relationship record;

[0013] The apportionment benchmark identifier is determined based on the occupancy relationship record, resource type, and process type, and the apportionment rule smart contract in the blockchain is invoked to generate a collection lock key. The collection lock key is formed by the accounting boundary identifier, the shared resource identifier, the resource occupancy time window, the resource consumption summary identifier, and the apportionment rule version.

[0014] When the collection lock key hits an existing collection lock key whose status of the associated order carbon footprint voucher is pending collection, collected, pending review, confirmed, or added, a duplicate collection prompt is generated, and the generation of new order-level carbon load allocation records is terminated.

[0015] When the aggregation lock key is not hit, an order-level carbon load allocation record is generated, and the aggregation lock key is set to the aggregation lock state;

[0016] Based on the order carbon footprint certificate, order-level carbon load allocation record, and emission factor version information, an order-level carbon footprint assessment result is generated, and the result hash, allocation rule version, and certificate status of the order-level carbon footprint assessment result are written into the blockchain.

[0017] In some embodiments, the outsourced surface treatment order data includes order identifier, part identifier, process type, accounting boundary identifier, and delivery batch information;

[0018] The process event data includes event type, event time, equipment identifier, shared resource identifier, order identifier, and event status.

[0019] In some embodiments, when generating an order process event chain, the events are sorted according to the time of loading, entering the tank, exiting the tank, entering the furnace, exiting the furnace, drying, cleaning, waiting, rework, or scrapping, and event flags are set based on the order identifier, shared resource identifier, event time, and resource occupation time window; when adjacent occupation segments of the same order on the same shared resource meet the continuous interval threshold and there is no waiting, line change, shift cross, rework, scrapping and redo, abnormal line stop or manual data entry status, a continuous occupation event flag is set;

[0020] When the aforementioned waiting, line switching, shift crossing, rework, scrapping and redoing, abnormal line stoppage, or manual data entry status exists, or when adjacent occupied segments exceed the continuous interval threshold, an intermittent occupation event flag is set.

[0021] In some embodiments, when at least two order identifiers exist within the same resource occupancy time window, and the corresponding occupancy segments effectively overlap with the resource occupancy time window, a shared occupancy event flag is set;

[0022] The continuous occupancy event markers, intermittent occupancy event markers, and shared occupancy event markers are written into the order process event chain and used as input data for the allocation rule smart contract to identify the allocation benchmark, determine additional carbon load events, and generate occupancy relationship records.

[0023] In some embodiments, the resource consumption summary is obtained from resource activity data through metering aggregation and summary processing, and includes resource consumption summary identifier, resource category, metering interval, consumption amount, metering device identifier, and summary generation time;

[0024] The off-chain original data hash, data provider signature, and data timestamp are associated with the resource consumption summary and written into the blockchain.

[0025] In some embodiments, the allocation benchmark identifier includes a processing area benchmark, a loading capacity benchmark, an occupancy time benchmark, a furnace batch benchmark, a process route benchmark, or a contaminant treatment benchmark;

[0026] The sharing rule smart contract determines the sharing benchmark identifier based on the process type, resource type, and event marker.

[0027] In some embodiments, the electroplating or anodizing process corresponds to the processing area benchmark, the time occupied benchmark, or the process route benchmark; the heat treatment process corresponds to the furnace batch benchmark, the loading capacity benchmark, or the time occupied benchmark; and the wastewater treatment process corresponds to the pollutant treatment benchmark or the process route benchmark.

[0028] In some embodiments, when events such as replating, rework, reheat treatment, scrapping and rework, temporary waiting, or abnormal line stoppage occur in the order process event chain, an additional carbon load event is generated, and the original order carbon footprint certificate identifier, abnormal event type, additional shared resource identifier, additional allocation rule version, and additional certificate status are written into the order carbon footprint certificate.

[0029] In some embodiments, when the off-chain original data hash, resource consumption summary, allocation rule version, emission factor version, or order process event chain changes, a version change event is generated, and the credential status before the change, the credential status after the change, and the version change event are written to the blockchain.

[0030] Secondly, embodiments of the present invention provide a blockchain-based carbon footprint monitoring and assessment system, including:

[0031] It includes an order voucher generation module, a process event processing module, a shared resource ledger module, an occupancy relationship generation module, a smart contract execution module, an evaluation result generation module, and a blockchain evidence storage module;

[0032] The order voucher generation module is used to generate order carbon footprint vouchers;

[0033] The process event processing module is used to generate an order process event chain;

[0034] The shared resource ledger module is used to generate shared process resource ledger objects;

[0035] The occupancy relationship generation module is used to generate occupancy relationship records when an occupancy event falls within the resource occupancy time window.

[0036] The smart contract execution module is used to generate a collection lock key, generate a duplicate collection prompt or an order-level carbon load allocation record based on the collection lock key, and set the collection lock key to a collection lock state.

[0037] The assessment result generation module is used to generate order-level carbon footprint assessment results;

[0038] The blockchain evidence storage module is used to write the result hash, the allocation rule version, and the certificate status.

[0039] Through the above technical solution, the present invention can achieve at least the following beneficial effects:

[0040] This invention matches occupancy events in the order process event chain with resource occupancy time windows in the shared process resource ledger object to form an occupancy relationship record between order identifier, shared resource identifier, and occupancy events. Based on the accounting boundary identifier, shared resource identifier, resource occupancy time window, resource consumption summary identifier, and allocation rule version, a collection locking key is generated, so that shared resource consumption completes on-chain hit determination before entering the order-level carbon load allocation record. When the existing collection locking key is hit, a duplicate collection prompt is generated; when it is not hit, an order-level carbon load allocation record is generated, thereby forming a verifiable association between order events, resource consumption, allocation basis, and on-chain vouchers in the outsourced shared process.

[0041] By recording resource occupancy time windows, resource consumption summaries, and resource consumption summary identifiers in the shared process resource ledger object, equipment-level resource consumption is given a time window index that matches the order occupancy event.

[0042] By generating an order process event chain according to the order identifier and event time, and setting continuous occupation event markers, intermittent occupation event markers, and shared occupation event markers, order insertion, cross-shift, waiting, mixed loading, and shared occupation can form event states that can be read by the allocation rule smart contract.

[0043] By generating additional carbon load events when events such as replating, rework, reheat treatment, scrapping and rework, temporary waiting, or abnormal line stoppage occur, the additional resource consumption caused by abnormal processing can be linked to the original order's carbon footprint voucher for recording.

[0044] By writing the hash of the original off-chain data, the signature of the data provider, the data timestamp, the hash of the result, the version of the sharing rules, and the status of the voucher into the blockchain, the principal can verify the correspondence between the order-level carbon footprint assessment results and the off-chain resource consumption data based on the on-chain digest. Attached Figure Description

[0045] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation on the scope of this application.

[0046] Figure 1 This is a flowchart of the blockchain-based carbon footprint monitoring and assessment method in the embodiments;

[0047] Figure 2 This is a framework diagram of the blockchain-based carbon footprint monitoring and assessment system in the embodiment. Detailed Implementation

[0048] 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.

[0049] All terms used in this application (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0050] Furthermore, for ease of understanding, the relevant terms and concepts involved in the embodiments of this application will be introduced below:

[0051] An order carbon footprint voucher is a data record indexed by the order identifier, used to record accounting boundary identifiers, process events, occupancy relationships, allocation records, assessment results, and voucher status. An order process event chain is a data chain formed according to the same order identifier and event time sequence, used to represent the process flow status of an order during outsourced processing. A shared process resource ledger object is a data object indexed by a shared resource identifier, used to record the resource type, resource occupancy time window, resource consumption summary, and resource consumption summary identifier of production or auxiliary resources shared by multiple orders. The processing party system is a collection of systems used by the processing party to generate order, process, equipment operation, energy collection, and environmental treatment data, including at least one of a production management system, an energy collection system, and a process recording system.

[0052] Occupancy records are data records used to describe the occupancy correspondence between the order process event chain and the shared process resource ledger object. Order-level carbon load allocation records are data records output by the allocation rule smart contract, used to represent the results of the shared resource consumption being aggregated into the order carbon footprint voucher.

[0053] The accounting boundary identifier is a data identifier used to identify the scope of order-level carbon footprint accounting. The corresponding accounting scope includes the scope of processes involved in the order, the scope of shared resources, the scope of resource occupancy time, and the scope of application of emission factors. Emission factor version information is a data record used to identify the source, energy category, applicable time, unit caliber, and version identifier of emission factors. The resource consumption summary identifier is a unique identifier for the resource consumption summary, used to establish a correspondence with the occupancy relationship record, the aggregation locking key, and the off-chain original data hash. The voucher status is the status value of the order carbon footprint voucher during the processes of aggregation, review, confirmation, addition, cancellation, and modification, including pending aggregation, aggregated, pending review, confirmed, added, and cancelled states. Version change events are data records generated when the off-chain original data hash, resource consumption summary, allocation rule version, emission factor version, or order process event chain changes. Integrity verification checks the integrity of fields and signature consistency of version change events. Verification fields include the order carbon footprint voucher identifier, the object of the change, the summary before the change, the summary after the change, the change time, the data provider's signature, the version identifier after the change, and the voucher status after the change. When the object of the change is an allocation rule version, the version identifier after the change is the allocation rule version after the change. Anomaly verification records are used to record data that cannot be directly generated from the allocation rule smart contract for order-level carbon load allocation. These records include occupancy relationship records, anomaly type, trigger time, voucher status of associated order carbon footprint vouchers, and processing status.

[0054] The aggregation lock status refers to the status value corresponding to the aggregation lock key, including active lock status, historical lock status, and duplicate aggregation prompt status. Active lock status indicates that the corresponding aggregation lock key participates in a new duplicate aggregation determination; historical lock status indicates that the corresponding aggregation lock key is used for retrospection; and duplicate aggregation prompt status indicates a prompt status formed after a candidate determination key matches the active aggregation lock key set. A candidate determination key is a query key generated by the allocation rule smart contract based on the key-value field of the aggregation lock key for a new occupancy relationship record. The active aggregation lock key set consists of aggregation lock keys that are in the active lock status and whose associated order carbon footprint vouchers are in the pending aggregation, aggregated, pending review, confirmed, or appended status.

[0055] Example 1:

[0056] like Figure 1 As shown, this embodiment employs a blockchain-based carbon footprint monitoring and assessment method, applied to an outsourced surface treatment order scenario, including:

[0057] Step S1: Receive outsourced surface treatment order data and generate an order carbon footprint certificate corresponding to the order identifier;

[0058] Step S2: Receive process event data generated by the processing system, and generate an order process event chain according to the same order identifier and event time;

[0059] Step S3: For shared process resources jointly occupied by multiple orders, a shared process resource ledger object is generated. Shared process resources include at least one of the following: tank liquid, furnace, hanger, drum, drying line, pure water system, air compressor system, and wastewater treatment system. The shared process resource ledger object records the shared resource identifier, resource type, resource occupation time window, resource consumption summary, and resource consumption summary identifier. When an occupation event in the order process event chain falls into the resource occupation time window, the order identifier, shared resource identifier, and occupation event are written into the occupation relationship record.

[0060] Step S4: Determine the allocation benchmark identifier based on the occupancy relationship record, resource type, and process type, and call the allocation rule smart contract in the blockchain to generate an aggregation lock key associated with the corresponding resource consumption summary;

[0061] Step S5: The aggregation lock status is recorded through the aggregation lock key. The aggregation lock key is formed by the accounting boundary identifier, the shared resource identifier, the resource occupancy time window, the resource consumption summary identifier, and the allocation rule version. Before generating the order-level carbon load allocation record, the allocation rule smart contract queries the aggregation lock key. If the same aggregation lock key already exists, and the certificate status of the order carbon footprint certificate is in the aggregated state, the pending review state, or the confirmed state, a duplicate aggregation prompt is generated, the occupancy relationship record that triggers the duplicate aggregation prompt is recorded, and the generation of a new order-level carbon load allocation record is terminated.

[0062] Step S6: When the certificate status of the order carbon footprint certificate is invalid, and there is no version change event that changes the certificate status to pending collection, collected, pending review, confirmed, or appended, retain the original collection lock key status and write the occupancy relationship record that triggers the status into the exception verification record; when there is a version change event and the version change event passes the integrity verification, generate a new collection lock key based on at least one of the changed allocation rule version and the changed resource consumption summary identifier, and set the original collection lock key to the historical lock status;

[0063] Step S7: Generate an order-level carbon footprint assessment result based on the order carbon footprint certificate, order-level carbon load allocation record, and emission factor version information. Write the result hash, allocation rule version, and certificate status of the order-level carbon footprint assessment result into the blockchain. The order-level carbon footprint assessment result includes the order identifier, accounting boundary identifier, order-level carbon load allocation record, emission factor version information, assessment generation time, result hash, and certificate status.

[0064] In one implementation, the shared process resource ledger object is generated according to the shared resource identifier, and the resource occupancy time window is determined by the start time, end time, operating status, and metering cycle of the shared resource. The resource consumption summary is obtained from the resource activity data through metering aggregation and summary processing.

[0065] Specifically, the metering interval is the period from the start to the end of the metering corresponding to the resource activity data, and the consumption is the resource usage recorded by the metering equipment or the processing system within this metering interval. Resource activity data comes from at least one of the following: energy metering equipment, equipment operation records, process record data, and environmental treatment data. When multiple data sources exist for the same shared resource within the same metering interval, the data with the metering equipment identifier and the data provider's signature is used as the master data, and the process record data from the processing system is used as the alignment data. The off-chain raw data hash is generated jointly by the off-chain raw data, the metering interval, the metering equipment identifier, and the data timestamp, and is associated with the resource consumption summary identifier.

[0066] Occupancy records are generated by matching the order process event chain and the shared process resource ledger object. During matching, the order identifier, shared resource identifier, event time, and resource occupancy time window are used as inputs. When the event time of an occupancy event falls within the resource occupancy time window, an occupancy record is generated. The occupancy record includes the order identifier, shared resource identifier, occupancy event, event time, resource occupancy time window, event flag, and accounting boundary identifier. The allocation benchmark identifier is determined by the allocation rule smart contract based on the occupancy record, resource type, and process type, and written into the order-level carbon load allocation record. The event time of an occupancy event is based on the equipment event time recorded in the processor system; when the equipment event time is missing, the process start time or process end time in the process record data is used as a substitute time, and the corresponding occupancy record is written into the anomaly verification record. The resource occupancy time window is determined using a closed-beginning and open-beginning approach. When the occupancy event time equals the start time of the resource occupancy time window, it is assigned to that resource occupancy time window; when the occupancy event time equals the end time of the resource occupancy time window, it is assigned to the subsequent resource occupancy time window. Effective overlap refers to a temporal intersection between the occupied segment and the resource occupation time window, and the duration of the intersection reaches the calibration granularity of the resource occupation time window.

[0067] In one implementation, the outsourced surface treatment order data includes order identifier, part identifier, process type, accounting boundary identifier, and delivery batch information; the process event data includes event type, event time, equipment identifier, shared resource identifier, order identifier, and event status.

[0068] In one implementation, the off-chain raw data hash, data provider signature, and data timestamp are associated with a resource consumption summary and written to the blockchain;

[0069] In one implementation, the allocation benchmark identifier includes the processing area benchmark, loading capacity benchmark, occupancy time benchmark, furnace batch benchmark, process route benchmark, or contaminant treatment benchmark;

[0070] The allocation rule smart contract determines the allocation benchmark identifier based on the process type, resource type, and event marker;

[0071] The carbon load allocation rule smart contract receives the process type, resource type, occupancy relationship record, allocation benchmark identifier, resource consumption summary, and allocation rule version as input, and outputs an order-level carbon load allocation record. The order-level carbon load allocation record includes the order identifier, shared resource identifier, resource occupancy time window, allocation benchmark identifier, allocation rule version, allocation result summary, generation time, and contract execution status. The allocation rule version is stored in association with the process type, resource type, and allocation benchmark identifier to distinguish the aggregation criteria under different production conditions.

[0072] The allocation result summary is a result field in the order-level carbon load allocation record, used to represent the aggregation result of the resource consumption summary in the order carbon footprint certificate. The allocation result summary includes at least the resource consumption summary identifier, allocation benchmark identifier, aggregated resource consumption, emission factor version, allocation rule version, and allocation result hash. After the allocation rule smart contract generates the order-level carbon load allocation record, it writes the allocation result summary to the order carbon footprint certificate and writes the allocation result hash to the blockchain.

[0073] In one embodiment, the electroplating or anodizing process corresponds to the processing area benchmark, the time occupied benchmark, or the process route benchmark; the heat treatment process corresponds to the furnace batch benchmark, the loading capacity benchmark, or the time occupied benchmark; and the wastewater treatment process corresponds to the pollutant treatment benchmark or the process route benchmark.

[0074] When events such as replating, rework, reheat treatment, scrapping and rework, temporary waiting, or abnormal line stoppage occur in the order process event chain, an additional carbon load event is generated, and the original order carbon footprint certificate identifier, abnormal event type, additional shared resource identifier, additional allocation rule version, and additional certificate status are written into the order carbon footprint certificate.

[0075] Additional carbon load events are triggered by events in the order process event chain such as replating, rework, reheat treatment, scrapping and rework, temporary waiting, or abnormal line stoppage. Additional carbon load events include the original order carbon footprint voucher identifier, abnormal event type, additional shared resource identifier, additional resource occupancy time window, additional allocation benchmark identifier, additional allocation rule version, additional voucher status, and additional event time. Additional carbon load events are stored in association with the original order carbon footprint voucher and serve as a difference record when updating the order-level carbon footprint assessment results.

[0076] Additional carbon load events use the original order's carbon footprint voucher identifier as the associated index. When the additional resource occupancy time window overlaps with the original resource occupancy time window, the allocation rule smart contract first queries the corresponding aggregation lock key; if the set of active aggregation lock keys is matched, the additional carbon load event is written to the duplicate aggregation warning status; if the set of active aggregation lock keys is not matched, an order-level carbon load allocation record corresponding to the additional carbon load event is generated. The additional voucher status is used to identify the processing stage of the additional carbon load event, and the values ​​include pending aggregation, aggregated, pending review, confirmed, and voided.

[0077] In one implementation, when the off-chain original data hash, resource consumption summary, allocation rule version, emission factor version, or order process event chain changes, a version change event is generated, and the voucher status before the change, the voucher status after the change, and the version change event are written to the blockchain.

[0078] Version change events are triggered by changes to the off-chain raw data hash, resource consumption summary, allocation rule version, emission factor version, or order process event chain. Version change events include the order carbon footprint certificate identifier, the object of the change, the summary before the change, the summary after the change, the change time, the data provider's signature, and the certificate status after the change. The off-chain raw data is stored by the processor, while the blockchain stores the off-chain raw data hash, resource consumption summary, data provider's signature, and data timestamp. The client regenerates the hash of the off-chain raw data through an authorization verification interface and compares it with the off-chain raw data hash stored on the blockchain.

[0079] The authorization verification interface receives the order carbon footprint certificate identifier, resource consumption summary identifier, off-chain raw data hash, and data provider signature as input, and outputs the hash comparison result and signature verification result. When the hash comparison result matches and the signature verification result passes, a consistency record is established between the corresponding off-chain raw data and the blockchain storage content; when the hash comparison result is inconsistent or the signature verification result fails, an abnormal verification record is generated, and the certificate status of the associated order carbon footprint certificate is updated to pending review.

[0080] In a preferred embodiment of Example 1, when performing duplicate aggregation determination on aggregation lock keys in an active locked state, the allocation rule smart contract first generates candidate determination keys and queries the active aggregation lock key set before generating order-level carbon load allocation records; if the candidate determination key does not match the active aggregation lock key set, an order-level carbon load allocation record is generated, and the corresponding aggregation lock key is written into the active locked state.

[0081] The aggregation locking key uses the accounting boundary identifier, shared resource identifier, resource occupancy time window, resource consumption summary identifier, and allocation rule version as key-value fields. The start and end times of the resource occupancy time window are jointly calibrated using the blockchain timestamp, the metering sampling period, and the metering interval in the shared process resource ledger object. The calibration granularity uses 1 second and the shared resource identifier as the key-value field. The larger of the measurement sampling periods.

[0082] This calibration granularity is an implementation parameter used to standardize equipment event times, metering sampling periods, and resource occupancy time window boundaries. The metering sampling period is in seconds and is recorded by the metering equipment or the processing system. When a metering sampling period is missing, the metering sampling period corresponding to the most recent confirmed metering interval of the shared resource is used. When no confirmed metering interval exists, 60 seconds is used as the engineering caliber. This calibration granularity is only used for time window boundary alignment, effective overlap determination, and aggregation lock key generation, and does not participate in the measurement of resource consumption.

[0083] When calibrating resource occupancy time windows, the confirmed metering interval in the shared process resource ledger object is used as the primary time source. The blockchain timestamp is used to verify the writing order, and the metering sampling period is used to round the start and end times. When the resource occupancy time windows corresponding to the same shared resource identifier and the same resource consumption summary identifier have already formed window numbers, subsequent occupancy relationship records reuse the start and end times corresponding to that window number, and the manually entered time is used as a verification field for evidence storage.

[0084] When the serial number is The occupancy relationship record corresponds to the resource occupancy time window When this happens, the start time of the resource occupancy time window is recorded as... The end time of the resource occupancy time window is recorded as... .

[0085] The aggregation lock key is generated as follows:

[0086] ,

[0087] in, For the serial number The occupancy relationship record corresponds to the collection locking key; For on-chain hash functions; For the serial number The accounting boundary identifier corresponding to the occupancy relationship record; For the serial number The shared resource identifier corresponding to the occupancy relationship record, and its value corresponds to the aforementioned shared resource identifier. ; For the serial number The resource occupancy relationship record corresponds to the start time of the resource occupancy time window; For the serial number The resource occupancy relationship record corresponds to the end time of the resource occupancy time window; For the serial number The resource consumption summary identifier corresponding to the occupancy relationship record; For the serial number The occupancy relationship record corresponds to the allocation rule version; For field concatenation; Record the sequence number for the occupancy relationship.

[0088] When a version change event occurs on the blockchain, the resource consumption summary is regenerated, the allocation rule version is updated, or the original order carbon footprint certificate enters the invalid certificate state, the new aggregation locking key replaces the original allocation rule version with the changed allocation rule version, and uses the resource consumption summary identifier written in the changed occupancy relationship record as the identifier. Furthermore, a version change event identifier is added to the original key-value field to make the changed allocation record traceable and distinguishable from the original aggregation record.

[0089] ,

[0090] in, For the serial number The change collection lock key corresponding to the occupancy relationship record; For the serial number The changed apportionment rule version corresponding to the occupancy relationship record; For the serial number The version change event identifier corresponding to the occupancy relationship record; , , , , , , and The aforementioned definition will be used.

[0091] When the allocation rule smart contract receives a new occupancy relationship record, it generates a candidate decision key according to the same field order and time calibration as the original aggregation locking key; when At that time, candidate decision key Retrieve Collection Lock Key ;when Furthermore, when a version change event passes integrity verification, the candidate decision key... Take change collection lock key ;when Furthermore, when the version change event fails the integrity check, the candidate judgment key... Retrieve original set lock key And the corresponding occupancy relationship record is written into the anomaly verification record, where, An empty value for the version change event identifier.

[0092] Candidate decision keys are used for determining the hit rate of the activity aggregation lock key set and version binding. The original fields in the occupancy relationship record are retained as original evidence fields, and the duplicate aggregation decision value is written according to the candidate decision key.

[0093] ,

[0094] in, For the serial number The duplicate collection judgment value corresponding to the occupancy relationship record; For the serial number The candidate decision key corresponding to the occupancy relationship record; Set up a collection of lock keys for activities; The aforementioned definition will be used. A value of 1 indicates a hit, and a value of 0 indicates a pass.

[0095] When the duplicate allocation judgment value is a hit value, it means that the candidate judgment key corresponding to the new occupancy relationship record is consistent with the existing key in the active allocation lock key set. The allocation rule smart contract outputs a duplicate allocation prompt and terminates the generation of new order-level carbon load allocation records. When the duplicate allocation judgment value is a release value, the allocation rule smart contract continues to read the allocation benchmark identifier and resource type, and enters the order-level carbon load allocation record generation process.

[0096] For occupancy records with adjacent time window boundaries, the allocation rule smart contract uses a closed-beginning and open-beginning approach to read resource occupancy time windows. Specifically, if the occupancy event time falls within the start time of the resource occupancy time window but is earlier than its end time, it is considered to fall within that resource occupancy time window. If the occupancy event time equals the start time of the next resource occupancy time window, it is assigned to that window. This approach prevents the same occupancy event at the boundary of adjacent metering intervals from being simultaneously covered by two aggregation lock keys. For minor time offsets caused by shift changes, line changes, or metering delays, the allocation rule smart contract uses the resource occupancy time window already confirmed in the shared process resource ledger object as the standard; manually entered times are only used as verification fields for evidence storage.

[0097] After the version change event passes the integrity verification, the original aggregation lock key is retained in the blockchain, and its lock status is changed from active lock status to historical lock status; the changed aggregation lock key is added to the active aggregation lock key set.

[0098] The aforementioned status update is triggered by the time the version change event is written to the blockchain. Each trigger only affects the locked records corresponding to the same accounting boundary identifier, the same shared resource identifier, the same resource occupancy time window, and the same resource consumption summary identifier. If the version change event lacks a data provider signature, the changed allocation rule version, or the changed certificate status, the allocation rule smart contract maintains the active state of the original aggregation lock key and suspends the generation of new order-level carbon load allocation records based on this version change event; it also maintains the active state of the original aggregation lock key and suspends the generation of new order-level carbon load allocation records based on this change event. When the original order carbon footprint certificate enters the invalid certificate state but there is no changed certificate state, or the changed certificate state is invalid, the allocation rule smart contract retains the original aggregation lock key as an active lock and writes the corresponding occupancy relationship record into the anomaly verification record, without generating a changed aggregation lock key.

[0099] The collection lock key state is written according to the following rules:

[0100] when When this happens, the candidate determination result will be written to the duplicate collection prompt status. The existing activity collection lock key remains in the activity lock state. ;when and At that time, Write active lock state ;when , Furthermore, when the version change event passes the integrity check, the original collection lock key will be locked. Write historical lock state And change the collection lock key corresponding to Write active lock state ;when , Furthermore, if the version change event fails the integrity check, the original aggregation lock key will be maintained. Activity locked No change aggregation lock key is generated.

[0101] in, For the serial number The occupancy relationship record corresponds to the original collection lock key status; For the serial number The status of the change collection lock key corresponding to the occupancy relationship record; The activity is locked. It is in a historical locked state; This indicates a duplicate collection status; For the serial number The duplicate collection judgment value corresponding to the occupancy relationship record; For the serial number The version change event identifier corresponding to the occupancy relationship record; An empty value for the version change event identifier; The aforementioned definition will be used.

[0102] When a candidate decision key matches the active aggregation lock key set, the allocation rule smart contract only writes a duplicate aggregation warning status; the allocation rule version and voucher status of existing active aggregation lock keys are preserved. If the match occurs... In such scenarios, the version change event identifier is added as a verification field for evidence storage, and the allocation rule smart contract maintains the existing change aggregation lock key state.

[0103] Through the above processing, the collection lock key in the active lock state uses the resource consumption summary identifier as one of the on-chain judgment fields. The new occupancy relationship record is effectively distinguished by at least one key-value field among the accounting boundary identifier, shared resource identifier, resource occupancy time window, resource consumption summary identifier, allocation rule version or version change event identifier. When the candidate judgment key does not match the active collection lock key set, a new allocation process is entered. If the candidate judgment key does not match the active collection lock key set and a version change event is involved, the version change event passes the integrity check before entering a new allocation process. Occupancy relationship records that match the same collection lock key are identified as duplicate collection scenarios, and the allocation rule smart contract provides a duplicate collection prompt, thereby solidifying the control process of duplicate allocation of shared resources into an on-chain executable judgment mechanism.

[0104] Example 2:

[0105] Based on Example 1, this example provides a specific method for setting event markers according to continuous occupancy events, intermittent occupancy events, or shared occupancy events in a blockchain-based carbon footprint monitoring and assessment method;

[0106] When generating an order process event chain, the events are sorted according to the time of loading, entering the tank, exiting the tank, entering the furnace, exiting the furnace, drying, cleaning, waiting, rework, or scrapping. Event flags are set based on the order identifier, shared resource identifier, event time, and resource occupation time window. If adjacent occupation segments of the same order on the same shared resource meet the continuous interval threshold and there is no waiting, line change, shift change, rework, scrapping and redo, abnormal line stoppage, or manual data entry status, a continuous occupation event flag is set.

[0107] When there is a waiting, line change, shift change, rework, scrapped and redone, abnormal line stop or manual data entry status, or when adjacent occupied segments exceed the continuous interval threshold, set an intermittent occupation event flag;

[0108] In one implementation, when at least two order identifiers exist within the same resource occupancy time window, and the corresponding occupancy segments effectively overlap with the resource occupancy time window, a shared occupancy event flag is set.

[0109] Continuous occupancy event markers, intermittent occupancy event markers, and shared occupancy event markers are written into the order process event chain and used as input data for the allocation rule smart contract to identify the allocation benchmark, determine additional carbon load events, and generate occupancy relationship records;

[0110] Event markers are generated based on order identifier, shared resource identifier, event time, resource occupancy time window, and interruption status identifier.

[0111] In a preferred embodiment of Example 2, when generating an order process event chain, events such as loading, entering the tank, exiting the tank, entering the furnace, exiting the furnace, drying, cleaning, waiting, rework, or scrapping are first organized into occupied segments according to the same order identifier, the same shared resource identifier, and the same event time. Each occupied segment starts with the event time of entering the shared resource and ends with the event time of exiting or releasing the shared resource. For occupied segments that lack a release event but have already had an event for the next process to enter, if the measurement deadline of the process to which the occupied segment belongs exists, that measurement deadline is used as the end time; if the measurement deadline is missing, the occupied segment is written into the anomaly verification record, and the generation of the end time of the occupied segment is suspended. The anomaly verification record is used to record occupied segments that lack a release event, have inverted event times, or have missing measurement deadlines.

[0112] The determination of consecutive occupancy events is based on the interval between adjacent occupancy segments of the same order on the same shared resource. The consecutive interval threshold is calibrated according to the resource type, and the calibration method is as follows:

[0113] ,

[0114] in, Shared resources are identified as The continuous interval threshold; Shared resources are identified as The upper limit of the continuous interval threshold; Shared resources are identified as The lower limit of the continuous interval threshold; Set of historical normal continuous operation intervals Median level quantile values; Shared resources are identified as The set of historical normal continuous operation intervals; Shared resources are identified as The corresponding quantile level; Shared resources are identified as The corresponding metering sampling compensation coefficient; Shared resources are identified as The metering sampling period.

[0115] The historical set of normal continuous operation intervals consists of adjacent occupancy intervals formed by the same shared resource within the confirmed normal metering interval. A confirmed normal metering interval is a metering interval where the equipment identifier, shared resource identifier, metering equipment identifier, resource occupancy time window, data provider signature, and voucher status are all complete, and the corresponding occupancy segment has not been written into the anomaly verification record. The continuous interval threshold is an implementation parameter, measured in seconds, and its value is jointly determined by the quantile value of the historical normal continuous operation interval set, the metering sampling period, and the resource type. When the number of valid samples is lower than the lower limit of the sample number, the previous valid continuous interval threshold is used; if the previous valid continuous interval threshold is missing, the lower limit of the continuous interval threshold for the corresponding resource type is used.

[0116] The aforementioned continuous interval threshold is triggered for updating after the shared process resource ledger object completes a measurement interval and the corresponding resource consumption summary is written. The update window takes the most recent preset number of confirmed normal measurement intervals, or the most recent preset time span of confirmed normal measurement intervals. When abnormal line stoppages, missing measurements, cross-shift record gaps, or manual data entry events occur, the abnormal interval is suspended from participating in threshold calibration, and the previous valid continuous interval threshold is used. The direction of change of the continuous interval threshold is constrained by the resource type. The continuous interval threshold for fixtures, rollers, drying lines, pure water systems, and air compressor systems increases with the increase of stable operating intervals, while the threshold for tank solutions, furnaces, and wastewater treatment systems converges to the lower limit when frequent line changes or inter-batch waiting occur.

[0117] When the number of valid samples in the update window is lower than the preset lower limit of the number of samples, the update of the continuous interval threshold is paused, and the previous valid continuous interval threshold is used. If there is no previous valid continuous interval threshold, the preset lower limit of the continuous interval threshold for the corresponding resource type is used as the conservative threshold. After each continuous interval threshold update, the threshold version identifier is written into the corresponding order process event chain. The threshold version identifier is only used for event marking review and version traceability.

[0118] The adjacent occupancy interval for the same order on the same shared resource is calculated using the following formula:

[0119] ,

[0120] in, The order is identified as Shared resources are identified as follows Serial number is The adjacent occupancy interval between the currently occupied segment and the previous occupied segment; The order is identified as Shared resources are identified as follows Serial number is The start time of the currently occupied segment; The order is identified as Shared resources are identified as follows Serial number is The end time of the previous occupied segment; For order identification; For identifying shared resources; This refers to the sequence number of the segment occupied by the same order on the same shared resource.

[0121] when If the occupied segment has no preceding occupied segment, the adjacent occupied interval is not included in the continuous occupied determination. If the occupied segment does not meet the shared occupied condition and the interruption status flag is 0, then the initial continuous resource occupied period is formed according to the current occupied segment. If the adjacent occupied interval is negative, the end time of the current occupied segment is earlier than the start time, or either the start time or the end time is missing, then the corresponding occupied segment is written to the anomaly verification record, and the interruption status flag is set to 1.

[0122] The determination of shared resource occupancy events is based on the number of concurrent orders within the resource occupancy time window:

[0123] ,

[0124] in, Shared resources are identified as Resource usage time window number is The number of concurrent orders within the same period; Shared resources are identified as Resource usage time window number is Resource usage time window; , , and The aforementioned definition will be used; This refers to the time window number of resource occupancy on the same shared resource; The order is identified as Shared resources are identified as follows Serial number is The end time of the currently occupied segment; Indicates the number of elements in the set; Indicates the intersection of time intervals; It is an empty set.

[0125] The resource occupancy time window calibration granularity is used to calibrate the start and end times of the resource occupancy time window in the aggregation locking key. In the statistics of the number of concurrent orders, the intersection in the formula is not empty if the intersection duration of the occupied segment and the resource occupancy time window reaches the resource occupancy time window calibration granularity. Boundary contact events with an intersection duration lower than this calibration granularity are stored as time boundary verification information, are not included in the number of concurrent orders, and do not trigger the shared occupancy event flag.

[0126] The interruption status identifier is a data value used to indicate that an interruption occurs during the operation of an occupied segment. The interruption status identifier is set to 1 when at least one of the following states occurs within the occupied segment: waiting, line change, shift change, rework, scrapping and redo, abnormal line stoppage, or manual data entry. The interruption status identifier is set to 0 when none of the above states occur within the occupied segment. The manual data entry status is generated by the manual entry identifier recorded in the processing system and is only used as an input field for event marking and anomaly verification records.

[0127] Event markers are written into the order process event chain in the following order: shared usage takes priority, intermittent usage takes second priority, and continuous usage is the last resort.

[0128] like Furthermore, the occupied segment is counted in the order's concurrent quantity according to the effective overlap criterion. ;

[0129] like and ,but ;

[0130] like and ,but ;

[0131] in, The order is identified as Shared resources are identified as follows Serial number is The event marker corresponding to the occupied fragment; Mark the shared occupancy event; Mark the intermittent occupancy event; Mark continuous occupancy events; The order is identified as Shared resources are identified as follows Serial number is The interrupt status identifier corresponding to the occupied segment; , , , , and Following the previous definitions, the shared occupancy event flag is used to trigger the allocation rule smart contract to read the allocation benchmark identifier; the intermittent occupancy event flag is used to use the resource idle time caused by waiting, line switching, or shift crossing as the basis for the allocation rule smart contract to select the occupancy time benchmark or generate additional carbon load events; the continuous occupancy event flag is used to merge adjacent occupancy segments into a continuous resource occupancy period of the same order.

[0132] When both the shared occupancy condition and the intermittent occupancy condition are met, the event flag is written to the shared occupancy event flag, and the value of the interruption status flag is retained; the allocation rule smart contract reads the shared occupancy event flag for shared resource allocation, and at the same time reads the interruption status flag to determine whether to generate an additional carbon load event or write an anomaly verification record.

[0133] Thus, events in the order process event chain are arranged according to event time and converted into event states that can be identified for carbon load allocation.

[0134] Example 3:

[0135] Based on Example 1, this example provides a blockchain-based carbon footprint monitoring and assessment system, applied to outsourced surface treatment order scenarios, such as... Figure 2 As shown, it includes an order voucher generation module, a process event processing module, a shared resource ledger module, an occupancy relationship generation module, a smart contract execution module, an evaluation result generation module, and a blockchain evidence storage module;

[0136] The order voucher generation module is used to generate order carbon footprint vouchers;

[0137] The process event handling module is used to generate order process event chains;

[0138] The shared resource ledger module is used to generate shared process resource ledger objects;

[0139] The occupancy relationship generation module is used to generate occupancy relationship records when an occupancy event falls within the resource occupancy time window;

[0140] The smart contract execution module is used to generate a collection lock key, generate duplicate collection prompts or order-level carbon load allocation records based on the collection lock key, and set the collection lock key to the collection lock state;

[0141] The assessment results generation module is used to generate order-level carbon footprint assessment results;

[0142] The blockchain evidence storage module is used to write the result hash, the allocation rule version, and the certificate status.

[0143] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0144] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of this application and form different embodiments. For example, all the embodiments above can be used in any combination. The information disclosed in this background section is intended only to enhance the understanding of the general background of this application and should not be construed as an admission or in any way implying that such information constitutes prior art known to those skilled in the art.

Claims

1. A blockchain-based carbon footprint monitoring and assessment method, characterized in that, include: Receive outsourced surface treatment order data containing order identifiers and accounting boundary identifiers, and generate order carbon footprint vouchers; Receive process event data generated by the processing system and generate an order process event chain according to the same order identifier and event time; For shared process resources occupied by multiple orders, a shared process resource ledger object is generated. The shared process resources include at least one of the following: tank liquid, furnace, hanger, drum, drying line, pure water system, air compressor system and wastewater treatment system. The shared process resource ledger object records the shared resource identifier, resource type, resource occupation time window, resource consumption summary and resource consumption summary identifier. When the occupancy event in the order process event chain falls within the resource occupancy time window, the order identifier, shared resource identifier, and occupancy event are written into the occupancy relationship record; The apportionment benchmark identifier is determined based on the occupancy relationship record, resource type, and process type, and the apportionment rule smart contract in the blockchain is invoked to generate a collection lock key. The collection lock key is formed by the accounting boundary identifier, the shared resource identifier, the resource occupancy time window, the resource consumption summary identifier, and the apportionment rule version. When the collection lock key hits an existing collection lock key whose status of the associated order carbon footprint voucher is pending collection, collected, pending review, confirmed, or added, a duplicate collection prompt is generated, and the generation of new order-level carbon load allocation records is terminated. When the aggregation lock key is not hit, an order-level carbon load allocation record is generated, and the aggregation lock key is set to the aggregation lock state; Based on the order carbon footprint certificate, order-level carbon load allocation record, and emission factor version information, an order-level carbon footprint assessment result is generated, and the result hash, allocation rule version, and certificate status of the order-level carbon footprint assessment result are written into the blockchain.

2. The blockchain-based carbon footprint monitoring and assessment method according to claim 1, characterized in that, The outsourced surface treatment order data includes order identifier, part identifier, process type, accounting boundary identifier, and delivery batch information; The process event data includes event type, event time, equipment identifier, shared resource identifier, order identifier, and event status.

3. The blockchain-based carbon footprint monitoring and assessment method according to claim 1, characterized in that, When generating an order process event chain, the events are sorted according to the time of loading, entering the tank, exiting the tank, entering the furnace, exiting the furnace, drying, cleaning, waiting, rework, or scrapping. Event flags are set based on the order identifier, shared resource identifier, event time, and resource occupation time window. If adjacent occupation segments of the same order on the same shared resource meet the continuous interval threshold and there is no waiting, line change, shift change, rework, scrapping and redo, abnormal line stoppage, or manual data entry status, a continuous occupation event flag is set. When the aforementioned waiting, line switching, shift crossing, rework, scrapping and redoing, abnormal line stoppage, or manual data entry status exists, or when adjacent occupied segments exceed the continuous interval threshold, an intermittent occupation event flag is set.

4. The blockchain-based carbon footprint monitoring and assessment method according to claim 3, characterized in that, If at least two order identifiers exist within the same resource occupancy time window, and the corresponding occupancy segments effectively overlap with the resource occupancy time window, a shared occupancy event flag is set. The continuous occupancy event markers, intermittent occupancy event markers, and shared occupancy event markers are written into the order process event chain and used as input data for the allocation rule smart contract to identify the allocation benchmark, determine additional carbon load events, and generate occupancy relationship records.

5. The blockchain-based carbon footprint monitoring and assessment method according to claim 1, characterized in that, The resource consumption summary is obtained from resource activity data through metering aggregation and summary processing, and includes resource consumption summary identifier, resource category, metering interval, consumption amount, metering device identifier, and summary generation time; The off-chain original data hash, data provider signature, and data timestamp are associated with the resource consumption summary and written into the blockchain.

6. The blockchain-based carbon footprint monitoring and assessment method according to claim 1, characterized in that, The allocation benchmarks include processing area benchmarks, loading capacity benchmarks, occupancy time benchmarks, furnace batch benchmarks, process route benchmarks, or pollutant treatment benchmarks; The sharing rule smart contract determines the sharing benchmark identifier based on the process type, resource type, and event marker.

7. The blockchain-based carbon footprint monitoring and assessment method according to claim 6, characterized in that, Electroplating or anodizing processes correspond to processing area benchmarks, time occupancy benchmarks, or process route benchmarks; heat treatment processes correspond to furnace batch benchmarks, loading capacity benchmarks, or time occupancy benchmarks; and wastewater treatment processes correspond to pollutant treatment benchmarks or process route benchmarks.

8. The blockchain-based carbon footprint monitoring and assessment method according to claim 1, characterized in that, When events such as replating, rework, reheat treatment, scrapping and rework, temporary waiting, or abnormal line stoppage occur in the order process event chain, an additional carbon load event is generated, and the original order carbon footprint voucher identifier, abnormal event type, additional shared resource identifier, additional allocation rule version, and additional voucher status are written into the order carbon footprint voucher.

9. The blockchain-based carbon footprint monitoring and assessment method according to claim 1, characterized in that, When the off-chain original data hash, resource consumption summary, allocation rule version, emission factor version, or order process event chain changes, a version change event is generated, and the voucher status before the change, the voucher status after the change, and the version change event are written to the blockchain.

10. A blockchain-based carbon footprint monitoring and assessment system, based on the blockchain-based carbon footprint monitoring and assessment method according to any one of claims 1 to 9, characterized in that, It includes an order voucher generation module, a process event processing module, a shared resource ledger module, an occupancy relationship generation module, a smart contract execution module, an evaluation result generation module, and a blockchain evidence storage module; The order voucher generation module is used to generate order carbon footprint vouchers; The process event processing module is used to generate an order process event chain; The shared resource ledger module is used to generate shared process resource ledger objects; The occupancy relationship generation module is used to generate occupancy relationship records when an occupancy event falls within the resource occupancy time window. The smart contract execution module is used to generate a collection lock key, generate a duplicate collection prompt or an order-level carbon load allocation record based on the collection lock key, and set the collection lock key to a collection lock state. The assessment result generation module is used to generate order-level carbon footprint assessment results; The blockchain evidence storage module is used to write the result hash, the allocation rule version, and the certificate status.

Images