A Method and System for Carbon Trading Registration of Highways Based on Road Material Receipt and Transfer Chain

Abstract

This invention discloses a method and system for registering carbon trading on highways based on a road material claiming and transfer chain, relating to the field of carbon data processing technology. The proposed solution includes acquiring material flow collection data, carbon quota claiming data, and caliber mapping data. The material flow collection data includes batch identifiers and measurement values. The carbon quota claiming data includes claimed carbon quotas, registration caliber, and compliance period. The caliber mapping data includes measurement values, the transformation relationship between claimed carbon quotas and numerical boundaries. This application solves the problem that when the carbon factor caliber and compliance period are inconsistent across different stages, the preceding usage state cannot be identified on the same basis when entering a subsequent stage. This is achieved by uniformly transforming the measurement values ​​in the material flow collection data and the claimed carbon quotas in the carbon quota claiming data into the same registration dimension axis coordinate segments (receiving coordinate segment, claiming coordinate segment, and verification coordinate segment).

Description

Technical Field

[0001] This invention relates to the field of carbon data processing technology, and more specifically, this application relates to a method and system for registering carbon trading on highways based on a road material claim and transfer chain. Background Technology

[0002] During the construction and expansion of highways, road materials such as steel, cement, asphalt, aggregates, concrete components, and recycled materials flow continuously between production, transportation, construction, and reuse stages. Since each stage is typically recorded by different entities, systems, or project management units, the resulting measurement data, carbon emission data, and emission reduction contribution data often need to serve different purposes such as carbon trading registration, compliance deductions, project verification, or internal carbon asset management. Therefore, it is not only required that data from each individual stage be accountable, but also that the carbon credit status of the same batch of materials remains continuous, traceable, and verifiable after flowing through different stages.

[0003] Existing processing methods typically use the main body of the process or business system as the boundary, forming carbon credit records based on production energy consumption, transportation distance, construction consumption, or recycling substitution, and storing and submitting them according to their respective applicable carbon factors, registration standards, or compliance cycles. This method is relatively easy to implement within a single process, and its applicability is premised on the carbon credit status formed in the preceding process not substantially affecting the data judgment of the subsequent process, or even if there are differences, they can be handled through manual verification, data correction, or post-event comparison.

[0004] However, in the scenario of continuous flow of road materials, there is a natural connection between the upstream metering basis, transportation consumption, construction embedding amount, and reuse substitution contribution of the same batch of materials. When the carbon factor caliber, registration purpose, and cycle range adopted in different links are inconsistent, the part that has formed the usage status in the preceding data may be re-expressed as a different numerical range or registration range after entering the subsequent link. If the method of recording by link and comparing after the fact is still used, the system will find it difficult to identify the overlap, break and missing between the preceding and following links on the same data basis, which will easily lead to duplicate occupation, unclear scope to be verified, and difficulty in locating the source. Therefore, a method and system for highway carbon trading registration based on road material claiming and transfer chain is proposed to solve this problem. Summary of the Invention

[0005] To address the aforementioned technical issues, this paper provides a method and system for registering carbon trading on highways based on a road material requisition and transfer chain. This technical solution resolves the problems mentioned in the background section.

[0006] To achieve the above objectives, the technical solution of the present invention is as follows:

[0007] Firstly, this application provides a method for registering carbon trading on highways based on a road materials claim-and-transfer chain, the method comprising:

[0008] Acquire material flow collection data, carbon quota claim data, and caliber mapping data. The material flow collection data includes batch identifiers and measurement values. The carbon quota claim data includes claimed carbon quotas, registration calibers, and compliance periods. The caliber mapping data includes measurement values ​​and the transformation relationship between claimed carbon quotas and numerical boundaries.

[0009] The material flow data is aggregated according to the batch identifier to generate a batch stage sequence, and a transfer chain data structure is constructed with the stage sequence as the node and the stage time sequence as the directed edge.

[0010] Based on the caliber mapping data, the measurement values ​​of the stage nodes are transformed into the connecting coordinate segments located by the registration dimension and numerical boundary. The registration dimension is obtained from the registration caliber and the compliance period.

[0011] The upstream receiving coordinate segments are cumulatively transformed into downstream inherited coordinate segments along the data structure of the transfer chain, the claimed carbon amount is transformed into the claimed coordinate segments under the same registration dimension, and the missing stage events in the batch stage sequence are transformed into coordinate segments to be verified.

[0012] Extract the endpoint boundaries of the inherited coordinate segment, the claimed coordinate segment, and the coordinate segment to be verified, and divide them into minimum verification segments. Configure a multi-bit mask for each minimum verification segment. Perform bit setting operations on the inherited bit, claimed bit, and to be verified bit in the mask according to the type of the coordinate segment to which it is hit to form a segment overlay code.

[0013] Based on the setting status of the inheritance bit, claim bit, and unverified bit in the fragment overlay code, the minimum check segment is marked as a conflicting segment, a hanging segment, or a writable segment.

[0014] Obtain the requested carbon amount from the registration request, transform the requested carbon amount into a requested coordinate segment and align it with the minimum verification segment, read the segment coverage code covered by the requested coordinate segment, extract the overlapping sub-segments marked as writable segments as write segments, perform bit update on the segment coverage code corresponding to the write segment, and output the verification credentials containing the write segment, conflicting segment, hanging segment and corresponding stage node.

[0015] Secondly, this application provides a highway carbon trading registration system based on a road material claim-and-transfer chain, for implementing the aforementioned highway carbon trading registration method based on a road material claim-and-transfer chain, including:

[0016] The data acquisition module is used to acquire material flow collection data, carbon quota claim data and caliber mapping data. The material flow collection data includes batch identifiers and measurement values. The carbon quota claim data includes claimed carbon quotas, registration calibers and compliance periods. The caliber mapping data includes measurement values ​​and the transformation relationship between claimed carbon quotas and numerical boundaries.

[0017] The merging and chain building module is used to merge material flow collection data by batch identifier to generate batch stage sequences, and to build a transfer chain data structure with stage sequence as nodes and stage time sequence as directed edges.

[0018] The coordinate transformation module is used to transform the measurement values ​​of the stage nodes into the receiving coordinate segments located by the registration dimension and numerical boundary based on the caliber mapping data. The registration dimension is obtained from the registration caliber and compliance period.

[0019] The chain-derived module is used to transform the upstream receiving coordinate segments into the downstream inherited coordinate segments along the data structure of the transfer chain, transform the claimed carbon amount into the claimed coordinate segments under the same registration dimension, and transform the missing stage events in the batch stage sequence into coordinate segments to be verified.

[0020] The segmentation mask module is used to extract the endpoint boundaries of inherited coordinate segments, claimed coordinate segments, and coordinate segments to be verified and segment them into minimum verification segments. It configures a multi-bit mask for each minimum verification segment and performs bit-setting operations on the inherited bits, claimed bits, and to-be-verified bits in the mask according to the type of the coordinate segment it hits to form a segment overlay code.

[0021] The fragment marking module is used to mark the smallest parity segment as a conflicting fragment, a hanging fragment, or a writable fragment based on the setting status of the inherited bit, the claim bit, and the unverified bit in the fragment coverage code.

[0022] The request processing module is used to obtain the requested carbon amount in the registration request, transform the requested carbon amount into a requested coordinate segment and align it with the minimum verification segment, read the segment coverage code covered by the requested coordinate segment, extract the overlapping sub-segments marked as writable segments as write segments, perform bit update on the segment coverage code corresponding to the write segment, and output the verification credentials containing the write segment, conflict segment, hanging segment and corresponding stage node.

[0023] Thirdly, this application provides a computer device, the computer device including a memory and a processor, the memory storing code, the processor being configured to acquire the code and execute the above-described method for registering highway carbon trading based on road material claim and transfer chains.

[0024] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for registering highway carbon trading based on a road material claim and transfer chain.

[0025] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0026] This application solves the problem that the carbon factor caliber and compliance period of different links cannot be identified on the same basis after the previous usage status enters the subsequent link. It transforms the measurement value in the material flow collection data and the carbon quota in the carbon quota claim data into the same registration dimension number axis as the receiving coordinate segment, claiming coordinate segment and waiting verification coordinate segment. This makes the cross-caliber and cross-entity occupancy relationship transformed from the original numerical comparison to the interval occupancy comparison under the same reference system.

[0027] This application constructs a transfer chain data structure with batch identifier as primary key, stage sequence as node, and stage time sequence as directed edge, and transforms the upstream receiving coordinate segment into the downstream inherited coordinate segment along the transfer chain. This solves the problem that the same material is recorded separately by different entities across links and the carbon status is difficult to trace continuously. It enables the occupied range of any stage node to be traced back to the original metering basis along the transfer chain, and the receiving boundary of the subsequent links can be explicitly derived downstream.

[0028] This application solves the problem that the segment overlap, breakage and missing information cannot be identified by the segment recording and post-event manual comparison method. It enables the three types of anomalies to be atomically identified, located and intercepted when data is written. The application outputs the registration conclusion with a verification certificate containing the written segment, conflict segment, hanging segment and corresponding stage node. Attached Figure Description

[0029] The disclosure of this invention is illustrated with reference to the accompanying drawings. It should be understood that the drawings are for illustrative purposes only and are not intended to limit the scope of protection of this invention. Wherein:

[0030] Figure 1 This is a flowchart of the highway carbon trading registration method based on the road material claiming and transfer chain proposed in this invention;

[0031] Figure 2 This is a structural block diagram of the highway carbon trading registration system based on the road material claiming and transfer chain proposed in this invention. Detailed Implementation

[0032] It is readily understood that, based on the technical solution of this invention, those skilled in the art can propose various interchangeable structural methods and implementations without altering the essential spirit of the invention. Therefore, the following detailed embodiments and accompanying drawings are merely illustrative examples of the technical solution of this invention and should not be considered as the entirety of the invention or as limitations or restrictions on the technical solution of this invention.

[0033] Reference Figure 1 As shown, this application proposes an embodiment of a method for registering carbon trading on highways based on a road material claiming and transfer chain. The method is applicable to highway construction, reconstruction, expansion and maintenance projects, where road materials such as steel, cement, asphalt, aggregates, concrete components and recycled materials are continuously transferred in production, transportation, construction and recycling, and different construction units, construction units or material suppliers record data, use different carbon factor calibers and serve different registration purposes for different compliance periods.

[0034] To facilitate understanding, the following example uses a batch of steel material numbered B-001 with a measurement value of 50 tons in a highway reconstruction and expansion project. The material will subsequently go through four stages: steel production, road transportation, bridge construction, and recycling. It will also need to complete carbon trading registration for both the building material production and project performance aspects during the compliance period in the first quarter of 2025.

[0035] like Figure 1 As shown, the method in this application embodiment includes steps S1 to S7:

[0036] In step S1: acquire material flow collection data, carbon quota claim data and caliber mapping data. The material flow collection data includes batch identifier and measurement value. The carbon quota claim data includes claimed carbon quota, registration caliber and compliance period. The caliber mapping data includes measurement value and transformation relationship from claimed carbon quota to numerical boundary.

[0037] It should be noted that the material flow data is collected from the energy consumption metering system of the material production unit, the vehicle mileage and fuel consumption sensors in the transportation process, the material requisition and embedding records of the construction unit, and the warehousing ledger of the recycling unit. The collected data is associated with the events of each stage of the same material by batch identifier as the primary key. The carbon quota claim data comes from the claim applications submitted by various entities on the carbon trading registration platform. The claim application is jointly identified by the claimed carbon quota, the registration scope, and the compliance period corresponding to the claimed carbon quota. The scope mapping data is pre-released by the carbon trading registration agency, which provides the conversion relationship from the original measurement value (ton, vehicle-kilometer, cubic meter, etc.) to the numerical boundary under the same registration dimension for each combination of registration scope and compliance period.

[0038] It should also be noted that the batch identifier is used as the aggregation key, and the measured value and the claimed carbon credit are mapped to the numerical boundary of the same registration dimension. The reason is that in the scenario of highway reconstruction and expansion, when the same batch of materials is registered by different entities at different stages, the original measurement units are very different (energy consumption or output in the production stage, mileage in the transportation stage, embedded amount in the construction stage, and replacement amount in the recycling stage). If the original measurement value is directly compared between stages, it is impossible to identify whether the carbon credit of the same material has been occupied by the preceding stage.

[0039] Using the steel batch B-001 as an example, in the material flow data collection, the measurement value of batch B-001 is 50 tons in the steel production stage, 50 tons·300 kilometers in the transportation stage, and 50 tons in the embedded measurement value in the construction stage; in the carbon credit claim data, the steel production unit submitted a claim application for this batch, claiming a carbon credit of 80 tons of carbon dioxide equivalent, with the registration caliber being the building materials production caliber, and the compliance period being 2025Q1; in the caliber mapping data, the conversion relationship of the building materials production caliber under the 2025Q1 compliance period is "1.6 tons of carbon dioxide equivalent per ton of steel", and the conversion relationship of the project performance caliber under the same compliance period is "1.5 tons of carbon dioxide equivalent per ton of steel".

[0040] In step S2: material flow collection data is merged according to batch identifier to generate batch stage sequence, and a transfer chain data structure is constructed with stage sequence as node and stage time sequence as directed edge;

[0041] It should be noted that batch identification merging refers to aggregating all stage events with the same batch identification in the material flow data collection into a batch stage sequence, and sorting them according to the collection time point to form a stage trajectory from upstream production to downstream reuse; stage sequence refers to the position number of the batch in its stage sequence, and stage time sequence refers to the time direction from upstream to downstream between adjacent stage events.

[0042] The transfer chain data structure is one of the core data structures of this application. It uses the stage sequence as nodes and the stage time sequence as directed edges to connect the events of the same batch in the production, transportation, construction and recycling stages into a directed acyclic path. Each node is associated with the measurement value, collection time point and stage type of its respective stage, and each directed edge is associated with the time interval between the two nodes it connects.

[0043] Following the example of steel batch B-001, the batch stages are grouped by batch identifier to form the following sequence: [Steel production stage (50 tons) → Road transportation stage (50 tons, 300 km) → Bridge construction stage (50 tons) → Recycling and reuse stage (to be occurred)]. The corresponding transfer chain data structure contains 4 nodes and 3 directed edges, with node positions 1, 2, 3, and 4, corresponding to the stage types of production, transportation, construction, and reuse.

[0044] In step S3: The measurement values ​​of the stage nodes are transformed into the receiving coordinate segments located by the registration dimension and numerical boundary according to the caliber mapping data. The registration dimension is obtained from the registration caliber and compliance period.

[0045] It should be noted that the registration dimension refers to a one-dimensional numerical axis jointly identified by the registration scope and the compliance period; the numerical boundary refers to the starting and ending positions occupied by the measurement value of the stage node on this one-dimensional numerical axis; and the connecting coordinate segment is the ordered interval encapsulated by the starting and ending numerical boundaries. This indicates the carbon quota occupancy range of the event at this stage under the specified registration dimension; by unifying the measurement values ​​with huge differences in physical dimensions into coordinate segments on the same numerical axis, data generated by different links, different subjects, and different calibers can be superimposed, segmented, and compared under the same reference system.

[0046] Using the steel batch B-001 example, under the registration dimension formed by the construction material production caliber and the 2025Q1 compliance period: the measurement value of 50 tons at the steel production stage node is transformed into the receiving coordinate segment [0,80] after caliber mapping (i.e., occupying the position of 0 to 80 tons of carbon dioxide equivalent on the number axis of this registration dimension); the measurement value of 50 tons at the bridge construction stage node is also transformed into the receiving coordinate segment [0,80]; under the registration dimension formed by the project performance caliber and the 2025Q1 compliance period: the receiving coordinate segment of the steel production stage node is [0,75]; the receiving coordinate segment of the bridge construction stage node is [0,75]; the same stage node generates independent receiving coordinate segments under different registration dimensions, and the receiving coordinate segments do not interfere with each other, and participate in the subsequent cumulative transformation under their respective registration dimensions.

[0047] In step S4: the upstream receiving coordinate segment is cumulatively transformed into the downstream inherited coordinate segment along the data structure of the transfer chain, the claimed carbon amount is transformed into the claimed coordinate segment under the same registration dimension, and the missing stage events in the batch stage sequence are transformed into coordinate segments to be verified.

[0048] It should be noted that the inherited coordinate segment refers to the occupied range under the same registration dimension obtained by the downstream stage node based on the inherited coordinate segment of the upstream stage node, accumulated and transmitted along the directed edge of the transfer chain; the claimed coordinate segment refers to the occupied range formed after the claimed carbon quota is transformed into the numerical boundary under the same registration dimension through caliber mapping; the coordinate segment to be verified refers to the occupied range under the same registration dimension occupied by the missing stage event that should exist in the batch stage sequence but failed to collect complete data, which needs to be verified subsequently; the endpoint boundary of the coordinate segment to be verified of the missing stage event is determined by extending the predetermined occupied length downstream from the terminating numerical boundary of the inherited coordinate segment of its upstream adjacent stage node. The predetermined occupied length is determined based on the typical measurement value of this stage type in historical projects;

[0049] Following the example of steel batch B-001, under the construction material production caliber: the steel production stage is the starting point of the transfer chain, with no upstream, and its inherited coordinate segment directly adopts the receiving coordinate segment [0,80]; the inherited coordinate segment of the bridge construction stage accumulates the upstream receiving coordinate segment along the directed edge of the transfer chain, forming [0,80]. The steel production unit's claimed carbon amount of 80 tons of carbon dioxide equivalent is transformed into the claimed coordinate segment [0,80]. Assuming that the recycling and reuse stage has not yet occurred at the time of collection, this stage is a missing stage event. The preset occupancy length of 8 tons of carbon dioxide equivalent is extended downstream from the end value boundary of the inherited coordinate segment of the upstream construction stage, resulting in the coordinate segment to be verified [80,88].

[0050] In step S5: extract the endpoint boundaries of the inherited coordinate segment, the claimed coordinate segment, and the coordinate segment to be verified and divide them into minimum verification segments. Configure a multi-bit mask for each minimum verification segment. Perform bit setting operations on the inherited bit, claimed bit, and to-be-verified bit in the mask according to the type of the coordinate segment to which it is hit to form a segment overlay code.

[0051] It should be noted that the minimum check segment refers to the finest-grained interval between adjacent endpoint boundaries obtained by aggregating the start and end endpoint boundaries of all inherited coordinate segments, claimed coordinate segments, and coordinate segments to be verified under the same registration dimension, after deduplication and numerical sorting. A multi-bit mask refers to a status word configured for each minimum check segment, containing at least three covering bits: inherited bit, claimed bit, and to be verified bit. A fragment coverage code refers to a multi-bit mask after setting operations, where the set state of each covering bit indicates which types of coordinate segments cover the minimum check segment.

[0052] Following the example of steel batch B-001, under the construction material production caliber: the endpoint boundaries of the inherited coordinate segment [0,80], the claimed coordinate segment [0,80], and the coordinate segment to be verified [80,88] converge to {0,80,88}, which is divided into two minimum verification segments [0,80] and [80,88]. The minimum verification segment [0,80] is completely covered by both the inherited and claimed coordinate segments, and its fragment coverage code is (inherited bit=1, claimed bit=1, to be verified bit=0). The minimum verification segment [80,88] is completely covered by the coordinate segment to be verified, and its fragment coverage code is (inherited bit=0, claimed bit=0, to be verified bit=1).

[0053] In step S6: Based on the setting status of the inheritance bit, claim bit, and unverified bit in the fragment overlay code, the minimum check segment is marked as a conflicting segment, a hanging segment, or a writable segment.

[0054] It should be noted that a conflict segment refers to the smallest verification segment where both the inheritance and claiming bits are set, but their inheritance sources are inconsistent or inconsistent with their claiming sources. This corresponds to the situation in real-world scenarios where the carbon quota ranges of preceding and following stages overlap. A suspended segment refers to the smallest verification segment where only the pending verification bit is set, and neither the inheritance bit nor the claiming bit is set. This corresponds to a stage event in real-world scenarios where data collection is missing but the event should exist. A writable segment refers to the smallest verification segment where neither the inheritance bit nor the claiming bit is set, and neither the pending verification bit is set. This corresponds to a numerical range in real-world scenarios where new claiming requests can still be written.

[0055] Following the example of steel batch B-001, the segment coverage code of the minimum check segment [0,80] is (1,1,0). Since its inheritance source (upstream transmission during the steel production stage) and claim source (claim application from the steel production unit) are the same and have the same boundary, it is marked as a reconciled segment. If the steel production unit submits a second claim application covering the same registration dimension [40,100], then within the range [40,80], if both the inheritance bit and the claim bit are set but the claim source has two different claim application numbers, it will be marked as a conflicting segment. The segment coverage code of the minimum check segment [80,88] is (0,0,1), marked as a suspended segment, corresponding to a recycling stage where complete data has not yet been collected. Other ranges not covered by any coordinate segment (such as...) It is marked as a writable segment by default.

[0056] In step S7: obtain the requested carbon amount in the registration request, transform the requested carbon amount into a requested coordinate segment and align it with the minimum verification segment, read the segment coverage code covered by the requested coordinate segment, extract the overlapping sub-segments marked as writable segments as write segments, perform bit update on the segment coverage code corresponding to the write segment, and output the verification credentials containing the write segment, conflicting segment, hanging segment and corresponding stage node.

[0057] It should be noted that a registration request refers to a new claim application submitted by a registration entity on the carbon trading registration platform. The registration request includes the requested carbon credit, registration scope, compliance period, and target batch identifier; the request coordinate segment refers to the place range of the requested carbon credit after being mapped to the same registration dimension.

[0058] Using the steel batch B-001 example, assume that a highway construction unit submits a registration request for a carbon credit of 75 tons of CO2 equivalent for batch B-001 during the 2025Q1 compliance period and under the engineering performance caliber. This requested carbon credit is transformed into the request coordinate segment [0,75] through caliber mapping. Under the engineering performance caliber, the previously inherited coordinate segment is [0,75] (accumulated from the steel production stage along the transfer chain to the bridge construction stage), and the claimed coordinate segment is empty (no entity has submitted a claim under the engineering performance caliber). The request coordinate segment [0,75] is aligned with the minimum verification segment [0,75], and its segment coverage code is (inherited bit=1, claimed bit=0, pending verification bit=0), which is a writable segment. Therefore, the entire [0,75] is extracted as a write segment, and the claimed bit of the minimum verification segment is set to update it to (1,1,0).

[0059] It should be noted that the specific field composition of the verification voucher is explained in the following three scenarios:

[0060] The first scenario is that the registration request is fully accepted, and the verification certificate includes the following fields: registration request number, target batch identifier, registration scope, compliance period, numerical boundary of the written fragment, list of associated stage nodes, and writing time point; the example certificate is "{request number:REQ-2025-0312, batch:B-001, scope: engineering performance, compliance period:2025Q1, written fragment:[0,75], associated stage: steel production / road transportation / bridge construction, time point:2025-01-15T10:23:00}".

[0061] The second scenario involves a conflict between a registration request and an existing claim. The verification certificate includes the following fields: registration request number, the numerical boundary of the conflicting fragment, the claim application number and stage node of the conflict source, and the suggested handling method. An example certificate is "{Request number:REQ-2025-0313, Conflict fragment:[40,75], Conflict source:CLM-2025-0901 (steel production unit), Handling method: The applicant needs to negotiate with the conflict source entity to deduct or withdraw part of the claim}".

[0062] The third scenario involves a suspended fragment within the scope covered by the registration request. The verification voucher includes the following fields: registration request number, numerical boundaries of the suspended fragment, stage type and stage sequence of the corresponding missing stage event, and correction prompt. An example voucher is “{Request Number: REQ-2025-0314, Suspended Fragment: [80, 88], Missing Stage: Recycling and Reuse Stage (Sequence 4), Prompt: Recalculate after the recycling unit adds the missing fragment to the inventory ledger}”.

[0063] Through the above technical solution, this embodiment merges cross-stage flow events using batch identifiers as the primary key and constructs a transfer chain data structure based on stage sequence and stage timing. Then, it maps various measurement values ​​and claimed carbon quotas across dimensions to the numerical boundaries of the same registration dimension, thereby dividing them into minimum verification segments. It then uses the inheritance bits, claim bits, and pending verification bit operations of multi-bit masks to form a segment coverage code. Finally, it aligns and writes the request coordinate segment of the registration request with the segment coverage code. Unlike the existing processing method that records carbon quotas separately based on the main body of the process or business system and identifies overlaps and omissions through manual comparison afterward, this embodiment unifies all cross-stage, cross-caliber, and cross-subject occupied ranges onto the same reference axis when the data enters. This allows overlaps, breaks, and omissions to be identified all at once in the coverage bit state of the minimum verification segment. This provides a directly reusable transfer chain data structure and segment coverage code as a unified intermediate result for the subsequent subordinate processing steps S2 to S7 (event normalization, transfer coordinate segment generation, segment coverage code specific positioning, spectrum expansion, backflow cross-chain alignment, and suspended segment correction).

[0064] To improve the reliability of batch identification merging in step S2, event normalization processing is further included before generating the batch stage sequence by merging material flow collection data by batch identification.

[0065] It should be noted that the process of event standardization is as follows:

[0066] Sub-step 2.1: Extract batch identifiers, measurement values, collection times, and stage types from the material circulation data. Standardize the batch identifier format, unit of measurement, collection times format, and stage type name according to the preset field mapping relationship. Among them, the batch identifier is standardized as a two-segment format of "main number-sequence number", the unit of measurement is standardized as ton, vehicle-kilometer, and cubic meter according to the stage type, the collection times are standardized as ISO8601 format, and the stage type name is standardized as four standard names: production, transportation, construction, and reuse.

[0067] Sub-step 2.2: Under the same batch identifier, identify duplicate events based on the collection time and stage type—that is, multiple records of the same batch, the same collection time, and the same stage type, and retain the event with the highest field completeness (i.e., the largest number of non-empty fields) as the standard stage event, and discard the remaining duplicate events;

[0068] Sub-step 2.3: Reorder the events of the standard stage according to the collection time point, and generate the stage sequence number according to the change of stage type after rearrangement (such as from production to transportation, from transportation to construction). The stage sequence number starts from 1 and increments.

[0069] Sub-step 2.4: Mark the standard stage events that cannot form a continuous stage sequence with the preceding and following stages as missing stage events, and write the missing stage events into the batch stage sequence under the corresponding batch identifier; the basis for determining discontinuity is: there are intermediate stage types between adjacent stage types that should not be skipped according to the preset stage type change relationship (such as construction occurring directly after production without transportation).

[0070] Using the steel batch B-001 example, the following issues may exist in the raw material flow data collection: the steel production unit submits a batch identifier of "GCS-001" and a unit of measurement of "50 tons"; the transportation unit submits a batch identifier of "gcs001" and a collection time of "2025 / 12 / 05 14:00"; the construction unit submits a batch identifier of "GCS-0001" and a stage type name of "construction site embedding"; at the same time, the transportation unit submits two transportation events with the same time point, one of which is missing the fuel consumption field.

[0071] After event standardization: the batch identifier is uniformly "GCS-001"; the collection time of transportation events is uniformly "2025-12-05T14:00:00"; the stage type name of construction events is uniformly "Construction"; among repeated transportation events, the one with higher field completeness is retained; the stages are rearranged and generated according to the collection time as follows: sequence 1-production, sequence 2-transportation, sequence 3-construction; if the batch jumps directly from construction to project completion without the collection of reuse stage data, and the reuse stage should exist according to the preset stage type change relationship, then the reuse stage is marked as a missing stage event and written into the batch stage sequence.

[0072] It should be noted that for stage types that are reasonably nonexistent due to the entity's lack of participation in subsequent stages of the batch (such as the batch of steel not entering the recycling process), they will not be marked as missing stage events. The determination will be based on whether the downstream entity has registered the corresponding stage type of activity in the system for that batch.

[0073] Through the above technical solution, this embodiment unifies the batch identifier, unit of measurement, collection time point, and stage type name of the collected data according to the preset field mapping relationship, and retains the event with the highest field completeness under the same batch identifier as the standardized stage event. Then, the stage sequence is generated by rearranging according to the collection time point and missing stage events are identified. Unlike the processing method of directly merging without standardization, this embodiment eliminates the identifier conflict, unit conflict, time point format conflict and duplicate event conflict caused by the heterogeneity of the subject before merging. This ensures that when constructing the transfer chain data structure according to the batch identifier, multiple homogeneous chains or broken chains will not be generated due to the heterogeneity of the subject. The output standardized stage events and missing stage events are directly used as inputs for step S2 to construct the transfer chain data structure and step S4 to generate the coordinate segment to be verified.

[0074] To further clarify the specific transformation path from the measurement value to the receiving coordinate segment in step S3, the generation process of the receiving coordinate segment is elaborated as follows:

[0075] It should be noted that the process of generating the connecting coordinate segment is as follows:

[0076] Sub-step 3.1: According to the stage type corresponding to the stage node, read the caliber mapping entry that matches the registration caliber and compliance period from the caliber mapping data; the caliber mapping entry contains the unit conversion factor and starting reference position of the stage type under the registration caliber and compliance period;

[0077] Sub-step 3.2: Based on the caliber mapping entries, transform the measurement values ​​of the stage nodes into the starting and ending numerical boundaries under the same registration dimension. The starting numerical boundary is determined by the starting reference position, and the ending numerical boundary is determined by adding the measurement value to the starting reference position and multiplying it by the unit conversion factor.

[0078] Sub-step 3.3: Encapsulate the starting and ending numerical boundaries into a connecting coordinate segment according to numerical order. And associate the receiving coordinate segment with the corresponding stage node;

[0079] Sub-step 3.4: When there are multiple registration dimensions in the same stage node (i.e., the same stage event needs to participate in the registration of multiple registration standards or multiple compliance periods at the same time), generate the receiving coordinate segments under each registration dimension respectively, and make each receiving coordinate segment participate in the cumulative transformation of the subsequent inherited coordinate segments, and the receiving coordinate segments of each registration dimension do not interfere with each other.

[0080] Following the example of steel batch B-001, the measurement value for the steel production stage is 50 tons. Under the registration dimension formed by the construction material production caliber and the 2025Q1 compliance period, the caliber mapping entry is "Unit conversion factor = 1.6t". e / ton, initial reference position = 0", initial numerical boundary = 0, ending numerical boundary = 0 + 50 × 1.6 = 80, the bearing coordinate segment is [0, 80]; under the registration dimension formed by the project performance scope and the 2025Q1 compliance period, the scope mapping item is "unit conversion factor = 1.5t". e / ton, starting reference position = 0", the receiving coordinate segment is [0, 75]; the two receiving coordinate segments coexist and participate in the cumulative transformation of the inherited coordinate segments under their respective registered dimensions;

[0081] It should be noted that the starting reference position is not necessarily 0: when there is already a prior claim under the same registration dimension and the same batch of identifiers, the starting reference position of the newly generated receiving coordinate segment should be immediately adjacent to the termination value boundary of the prior claim to avoid overlapping starting positions. The specific rules for this continuation are specified by the "Starting Reference Anchoring Method" field of the caliber mapping entry, with options including "Start from Zero" and "Continue from Previous Termination".

[0082] Through the above technical solution, this embodiment retrieves the caliber mapping entries according to the stage type and determines the starting and ending numerical boundaries by the starting reference position and the unit conversion factor. Then, it encapsulates them into inheriting coordinate segments and generates them in parallel for multiple registration dimensions. Unlike the processing method of directly multiplying the measurement value by a single carbon factor to obtain a scalar value, this embodiment makes the occupied range of each stage node have a clear start and end point under the same registration dimension. The output inheriting coordinate segments are directly used as the source of the endpoint boundaries for accumulating into inherited coordinate segments along the inheritance chain in step S4 and splitting the minimum verification segment in step S5.

[0083] To further clarify the generation mechanism of the segment overlay code in step S5, the segmentation of the minimum parity segment and the bit setting operation of the multi-bit mask are elaborated as follows:

[0084] It should be noted that the process of generating the fragment overlay code is as follows:

[0085] Sub-step 4.1: Under the same registration dimension, gather the starting endpoint boundaries and ending endpoint boundaries of the inherited coordinate segments, claimed coordinate segments, and coordinate segments to be verified to form an endpoint boundary set.

[0086] Sub-step 4.2: Deduplicate and sort the endpoint boundary sets, and divide the range between adjacent endpoint boundaries into minimum verification segments; after division, any minimum verification segment... The interior no longer contains any endpoint boundaries of coordinate segments;

[0087] Sub-step 4.3: Configure each minimum check segment with inherited bits. Claiming a spot and the position to be verified The multi-bit mask is then initialized with each covered bit set to an unset state.

[0088] Sub-step 4.4: Perform containment matching between each minimum check segment and the inherited coordinate segment, claimed coordinate segment, and coordinate segment to be verified. For the minimum check segment completely covered by the corresponding coordinate segment, perform a bit-setting operation on the corresponding coverage bit. The containment relationship is determined based on: when the minimum check segment... Simultaneously satisfy The starting numerical boundary of this coordinate segment and When the coordinate segment terminates at the numerical boundary, it is determined to be completely covered;

[0089] Sub-step 4.5: Determine the multi-bit mask after the bit setting operation as the fragment overlay code, and store the fragment overlay code in association with the corresponding minimum parity segment.

[0090] Using the steel batch B-001 example, under the construction material production caliber, it is assumed that at this time, in addition to the claim application in the steel production stage (claim coordinate segment [0,80]), the transportation unit also submitted a claim application in the same registration dimension (claim coordinate segment [60,90]), and the recycling and reuse stage is a missing stage event (to be verified coordinate segment [80,88]), and the inherited coordinate segment is [0,80] (accumulated along the transfer chain to the bridge construction stage);

[0091] Following sub-step 4.1, the endpoint boundary set is collected as {0,60,80,88,90}. After deduplication and sorting in sub-step 4.2, it is divided into the smallest check segments [0,60], [60,80], [80,88], and [88,90]. The segment coverage code after performing bit-setting operations in sub-steps 4.3 and 4.4 is as follows:

[0092] Minimum check segment [0,60]: Completely covered by inherited coordinate segment [0,80] and claimed coordinate segment [0,80], segment coverage code is ;

[0093] Minimum check segment [60,80]: The inherited coordinate segment [0,80], the claimed coordinate segment [0,80], and the claimed coordinate segment [60,90] are all completely covered (there are two claims from different sources), and the segment coverage code is However, the source label of the claimed position points to two claim application numbers at the same time;

[0094] Minimum check segment [80,88]: Completely covered by both the coordinate segment to be verified [80,88] and the claimed coordinate segment [60,90], with the segment coverage code being... ;

[0095] Minimum check segment [88,90]: Completely covered only by the claimed coordinate segment [60,90], segment coverage code is .

[0096] It should be further explained that if the source tag of the claim position in the minimum verification segment [60,80] points to two different claim application numbers at the same time, it will be judged as a conflict segment in the marking step S6; if the claim position and the pending verification position are both set in the minimum verification segment [80,88], it means that there are both unrecovered stage events in this range and new claim applications occupying it, and it will be judged as a composite state of conflict segment and suspended segment; if only the claim position is set in the minimum verification segment [88,90], it means that the claimed carbon amount exceeds the upper limit of the range that the transfer chain can currently accept, and it will be judged as a conflict segment.

[0097] Through the above technical solution, this embodiment gathers the endpoint boundaries of all coordinate segments and divides them into the smallest verification segments that do not contain endpoints. Then, it matches multiple types of coordinate segments with inclusion relationships for each smallest verification segment and performs setting operations independently on the inherited bit, claim bit, and unverified bit. Unlike the processing method that compares overlapping coordinate segments as a whole, this embodiment enables any overlapping segment to be segmented into the smallest verification segment with a unique internal state for identification. The output segment coverage code is directly used as the criterion for collision, hanging, and writable three-state marking in step S6 and for aligning the requested coordinate segments and performing setting updates in step S7.

[0098] To address the situation in actual engineering projects where the flow of road materials is not strictly a single chain but involves batch splitting, batch merging, and mixed events, the genealogical extension of the transfer chain data structure is expanded as follows;

[0099] After constructing the transition chain data structure with stage sequence as nodes and stage time sequence as directed edges, further genealogical expansion processing is included, which includes batch splitting, batch merging, and mixed events.

[0100] It should be noted that the process of pedigree expansion is as follows:

[0101] Sub-step 5.1: Identify in the batch stage sequence events where there is a splitting of measurement values, a merging of measurement values, or mixing of different batches at the same stage position, and determine the batch splitting event, batch merging event, or mixed event based on the event combination; the determination criteria are as follows: a batch splitting event is when the same source batch identifier corresponds to multiple destination batch identifiers, a batch merging event is when multiple source batch identifiers correspond to the same destination batch identifier, and a mixed event is when there is a cross-correspondence between multiple source batch identifiers and multiple destination batch identifiers.

[0102] Sub-step 5.2: Based on the source batch identifier and destination batch identifier in the split batch event, merge batch event, or mixed event, generate the parent batch node, child batch node, and the phylogenetic directed edge connecting the parent batch node and the child batch node.

[0103] Sub-step 5.3: Generate the contribution weight of the directed edge of the spectrum based on the proportion of the measurement value or the proportion of the project belonging to the source batch identifier and the destination batch identifier; the contribution weight is a normalized decimal and the sum is 1.

[0104] Sub-step 5.4: Perform boundary segmentation on the receiving coordinate segments of the parent batch nodes according to the contribution weight, or perform boundary merging on the receiving coordinate segments of multiple parent batch nodes to generate the receiving coordinate segments of the child batch nodes;

[0105] Sub-step 5.5: Write the directed edges of the spectrum, contribution weights, and the receiving coordinate segments of the sub-batch nodes into the receiving chain data structure, and enable the receiving coordinate segments of the sub-batch nodes to continue to participate in the minimum check segment segmentation and fragment cover code generation.

[0106] Using the steel batch B-001 example and expanding the scenario, assume that batch B-001 is split into two destinations during the bridge construction phase: 30 tons for the main beam construction (to batch B-001-A) and 20 tons for the pier construction (to batch B-001-B). This event is a batch splitting event, identified by sub-step 5.1. Sub-step 5.2 generates the parent batch node B-001 and the child batch nodes B-001-A and B-001-B, as well as two spectral directed edges B-001→B-001-A and B-001→B-001-B. Sub-step 5.3 generates contribution weights based on the proportion of measured values: the contribution weight of B-001→B-001-A is 30 / 50=0.6, and the contribution weight of B-001→B-001-B is 20 / 50=0.4.

[0107] As per sub-step 5.4, under the building materials production caliber, the bearing coordinate segment of the parent batch node B-001 is [0,80]. Divided according to contribution weight, the bearing coordinate segment of the sub-batch node B-001-A is [0,48] (i.e., 0 to 80×0.6), and the bearing coordinate segment of the sub-batch node B-001-B is [48,80] (i.e., 80×0.6 to 80).

[0108] Consider the scenario of batch consolidation: Assume that during the pier construction phase, another batch of cement (B-002) of 10 tons (with a bearing coordinate segment of [0,8.5] under the cement building material production standard) needs to be mixed in, and poured together with 20 tons of steel from B-001-B to form the pier; this event is a batch consolidation event, the sub-batch node is B-PIER-01, and the directed edges of the spectrum are B-001-B→B-PIER-01 (contribution weight of 0.7, according to the project ownership ratio) and B-002→B-PIER-01 (contribution weight of 0.3); by sub-step 5.4, the bearing coordinate segment of the sub-batch node B-PIER-01 under the unified registration dimension is formed by merging the bearing coordinate segments of the parent batch node. The merging method is: the length of the bearing coordinate segment of the parent batch node is weighted and summed according to the contribution weight, and the length of the bearing coordinate segment of the sub-batch node is obtained by the weighted summation. The starting value boundary is immediately adjacent to the existing maximum ending value boundary under the same registration dimension.

[0109] To clarify, a hybrid event can be viewed as a combination of a split-batch event and a merge-batch event. First, the parent batch node's inheriting coordinate segments are divided according to the split-batch event. Then, the inheriting coordinate segments of the child batch nodes are merged according to the merge-batch event. After each child batch node generates its inheriting coordinate segment, it independently serves as the starting point of a new batch stage sequence, continuing to participate in the inherited coordinate segment cumulative transformation in step S4 and the minimum verification segment division in step S5.

[0110] It should be noted that when the contribution weight is inconsistent with the proportion of the measurement value (for example, in the same batch event, B-001-A actually only undertakes 30 tons of steel, but its project ownership ratio is set to 0.5 due to the requirements of the construction process), the contribution weight is generated based on the project ownership ratio as the priority, and the difference is marked in the transfer chain data structure for subsequent audit traceability; the flag of the priority basis is specified by the "weight anchoring method" field in the caliber mapping data.

[0111] Through the above technical solution, this embodiment identifies the events of value splitting, merging, and mixing at the same stage sequence position and generates parent batch nodes, child batch nodes, and spectral directed edges carrying contribution weights. Then, it performs boundary segmentation and boundary merging on the receiving coordinate segment according to the contribution weights. Unlike the processing method that treats batch splitting, merging, and mixing events as multiple independent single chains and then eliminates duplication through post-event verification, this embodiment explicitly encodes the share relationship between parent and child batches with spectral directed edges within the receiving chain data structure. This ensures that the occupancy range of any child batch can be traced back to the receiving coordinate segment of its parent batch and the sum is closed. The output spectral directed edges, contribution weights, and receiving coordinate segments of child batch nodes are directly used as inputs for step S4 accumulation along the receiving chain and step S5 segmentation of the minimum verification segment.

[0112] This embodiment's scheme for extending the genealogy of the transfer chain data structure under splitting, merging, and mixed events is based on the core concept of using "contribution weight to perform boundary segmentation and merging on the receiving coordinate segment" as a share closure mechanism under many-to-many batch relationships, rather than splitting the many-to-many relationship into multiple independent single chains for separate registration. The difference from existing technologies is that existing technologies usually only record the total amount before and after splitting or merging in the project ledger and rely on manual verification for consistency, which cannot guarantee share closure at the carbon quota registration data structure level. The genealogy extension scheme of this embodiment forces the sum of the lengths of the receiving coordinate segments of each sub-batch to be equal to the weighted sum of the lengths of the receiving coordinate segments of the parent batch at the data structure level, thereby replacing existing technologies such as "splitting / merging events are recorded by multiple chains and then the total amount is manually verified" and "allocating the carbon quota of the parent batch according to the average allocation coefficient".

[0113] To address the cross-chain backflow scenarios involving old and new batches in actual engineering projects (where old materials are recycled and reused to form recycled materials, which then enter the production process of new material batches in building materials), the cross-chain alignment of recycling and reuse backflow is elaborated as follows:

[0114] After transforming the missing stage events in the batch stage sequence into coordinate segments to be verified, the process further includes cross-chain alignment for recycling and reuse.

[0115] It should be noted that the cross-chain alignment process for recycled and reused materials is as follows:

[0116] Sub-step 6.1: Identify the recirculation event from the batch stage sequence where the old material batch forms recycled material in the recycling and reuse stage and enters the building material production stage of the new material batch; the identification basis is: the destination batch identifier of the old material batch in the recycling and reuse stage matches the source batch identifier of the new material batch in the building material production stage.

[0117] Sub-step 6.2: Based on the old material batch identifier, new material batch identifier, and return measurement value corresponding to the return event, establish a cross-chain directed edge between the old material batch's transfer chain data structure and the new material batch's transfer chain data structure. The cross-chain directed edge points from the recycling and reuse stage node of the old material batch to the building material production stage node of the new material batch.

[0118] Sub-step 6.3: Read the receiving coordinate segment and fragment coverage code of the old material batch recycling and reuse stage along the cross-chain directed edge, and transform the receiving coordinate segment into the return mapping coordinate segment of the new material batch building material production stage according to the caliber mapping data; the conversion relationship of the return mapping coordinate segment is specified by the "return emission reduction mapping entry" in the caliber mapping data, which is usually a negative value of the length of the receiving coordinate segment of the old material batch recycling and reuse stage (representing the carbon emissions avoided by the recycled material replacing the virgin material), or a negative value after conversion according to the preset replacement coefficient;

[0119] Sub-step 6.4: Incorporate the endpoint boundaries of the reflow mapping coordinate segments into the endpoint boundary set of the new material batch building material production stage, and re-divide the minimum verification segment affected by the newly added endpoint boundaries.

[0120] Sub-step 6.5: Based on the bit setting status of the fragment overlay code in the old material batch recycling and reuse stage, execute the inheritance bit or the pending verification bit setting for the minimum verification segment of the new material batch covered by the reflow mapping coordinate segment; when both the inheritance bit and the claim bit of the fragment overlay code in the old material batch recycling and reuse stage are set (i.e., the carbon amount of the old material batch recycling and reuse has been reconciled), execute the inheritance bit setting for the corresponding minimum verification segment of the new material batch; when the fragment overlay code of the old material batch is only pending verification bit (i.e., the data in the old material batch recycling and reuse stage is not yet complete), execute the pending verification bit setting for the corresponding minimum verification segment of the new material batch.

[0121] Using the steel batch B-001 as an example, assume that B-001 generates 10 tons of steel scrap during the recycling stage, which is then recycled to form a new material batch B-052 in the building materials production stage. Sub-step 6.1 identifies this as a recirculation event, with the old material batch being B-001, the new material batch B-052, and the recirculation measurement value being 10 tons. Sub-step 6.2 establishes a cross-chain directed edge B-001 (recycling stage) → B-052 (production stage). Sub-step 6.3 assumes that the receiving coordinate segment of the recycling stage of B-001 under the building materials production caliber is [80, 96] (i.e., an additional 16 tons of carbon dioxide equivalent are used in the recycling stage on top of the original 80 tons of carbon dioxide equivalent). The "Recirculation Emission Reduction Mapping Entry" in the caliber mapping data is "calculated as emission reduction based on the emission reduction coefficient of 1.2 for recycled steel replacing virgin steel," then the length of the recirculation mapping coordinate segment is 10 × 1.2 = 12. (In the negative direction), transform to the B-052 building materials production caliber axis. The original coordinate segment for the B-052 building materials production stage was [0,16] (10 tons of recycled steel is calculated as 1.6). (converted to / ton), the reflux mapping coordinate segment is [-12, 0] (i.e., extending 12 from 0 in the negative direction). As an emission reduction allowance.

[0122] Sub-step 6.4 merges the endpoint boundaries -12 and 0 of the reflow mapping coordinate segment into the endpoint boundary set of the B-052 building material production stage, and re-segments the minimum verification segment affected by the newly added endpoint boundaries. Sub-step 6.5 assumes the fragment coverage code of the B-001 reuse stage is... (Reconciliation completed), then the smallest check segment [-12,0] in B-052 will be bit-set using inheritance, and its fragment overlay code will be updated to... This indicates that the segment is an inherited amount that has been reconciled from B-001, and B-052 can submit a further claim application in this segment;

[0123] It should be noted that the cross-chain directed edge does not change the existing structure of the old material batch transfer chain, but only exists as an additional input edge of the new material batch transfer chain; when the subsequent state of the old material batch transfer chain changes (such as the fragment overlay code of the B-001 reuse stage changing due to correction), the change needs to be synchronized to the corresponding minimum check segment of the new material batch transfer chain along the cross-chain directed edge.

[0124] Through the above technical solution, this embodiment establishes a cross-chain directed edge by identifying the matching relationship between the destination of the old material batch in the recycling and reuse stage and the source of the new material batch in the building material production stage. Along the directed edge, the receiving coordinate segment of the old material is transformed into the return mapping coordinate segment of the new material. Then, according to the setting state of the old material fragment cover code, the minimum verification segment of the new material is executed with the inheritance bit or the pending verification bit. Unlike the processing method that treats the emission reduction credit of recycled material formed by recycling and reuse as an independent new registration record and cannot be traced back to the original material batch, this embodiment establishes an explicit cross-chain directed edge between the receiving and transfer chain data structures and synchronizes the reconciliation status of the old material to the fragment cover code of the new material, so that the emission reduction carbon credit of the recycled material has a traceable source batch basis. The output return mapping coordinate segment and the updated minimum verification segment are directly used as the input for the three states of marking conflict, hanging, and writable in step S6 and the alignment request coordinate segment in step S7.

[0125] The core concept of this embodiment regarding the cross-chain alignment scheme for recycling and reuse lies in using "cross-chain directed edges + recycle mapping coordinate segments + fragment overlay code status synchronization" as an explicit coding mechanism for the carbon credit inheritance relationship between old and new materials. The difference from the prior art is that in the prior art, the emission reduction credit of recycled materials is usually treated as an independent new registration item, which cannot be traced back to the original material batch, nor can the impact of the reconciliation status of the original material batch on the validity of the new material batch be identified. The cross-chain alignment scheme of this embodiment ensures that the carbon credit reduction of recycled materials always carries the reconciliation status information of its source batch, which can replace the existing technologies such as "independent registration of recycled material emission reduction credits" and "centralized accounting of recycled materials according to the average substitution coefficient".

[0126] For the subsequent processing of the closed-loop suspension segment, the correction of the suspension segment is carried out as follows:

[0127] After marking the minimum check segment as a conflict segment, a hanging segment, or a writable segment based on the setting status of the inherited bit, the claim bit, and the unverified bit in the segment overlay code, the process further includes correction processing for hanging segments.

[0128] It should be noted that the correction process for suspended segments is as follows:

[0129] Sub-step 7.1: Extract the stage node, registration dimension, endpoint boundary and segment coverage code corresponding to the suspended segment, and retrieve the corresponding missing stage event based on the stage node; extract the information to locate the missing stage event that should be corrected and its position in the transition chain data structure.

[0130] Sub-step 7.2: Obtain the correction event data that matches the missing stage event, and transform the measurement value or carbon credit claimed in the correction event data into a correction coordinate segment under the same registration dimension according to the caliber mapping data; the correction event data can come from the supplemented material flow collection data or from the supplemented carbon credit claim data, and the matching basis is that the batch identifier and stage type of the correction event data are consistent with the missing stage event.

[0131] Sub-step 7.3: Align the endpoints of the corrected coordinate segment with the minimum check segment corresponding to the dangling segment, and clear the unverified bits from the minimum check segment covered by the corrected coordinate segment (i.e., clear the unverified bits). (Set from 1 to 0), and set the inheritance bit or claim bit according to the source type of the correction event data: if the correction event data comes from material flow collection data, set the inheritance bit. The data for the correction event is derived from the carbon credit claim data; the claim bit is set. .

[0132] Sub-step 7.4: Re-mark the conflicting segments, dangling segments, or writable segments corresponding to the minimum check segment according to the updated segment overlay code, with the marking rules being the same as in step S6.

[0133] Following the example of steel batch B-001, the smallest check segment [80,88] is a suspended segment before correction, and its segment coverage code is... The corresponding missing stage event is the recycling and reuse stage.

[0134] Assume the recycling unit supplemented the material flow data collection for the recycling and reuse stage at the end of the first quarter of 2025, with batch identifier B-001, stage type "reuse," and a measurement value of 5 tons of recycled steel. Sub-step 7.2 transforms the measurement value of 5 tons in the supplementary event data into a correction coordinate segment according to the caliber mapping data. Under the building materials production caliber, the correction coordinate segment is [80, 88] (based on a conversion factor of 1.6 for the reuse stage). / ton). From sub-step 7.3, align the corrected coordinate segment [80,88] with the original suspended segment [80,88], clear the verification position and the position inheritance position (because the source is material flow collection data), and update the segment overlay code to ; As per sub-step 7.4, the updated fragment overwrite code has no conflicts or hanging status, and is re-marked as a writable fragment (in the claim dimension), awaiting subsequent claim requests;

[0135] It should be noted that if the measurement value of the corrected event data is inconsistent with the preset placeholder length of the suspended segment (e.g., the actual reuse measurement value is 6 tons while the preset placeholder length corresponds to 8 tons of carbon dioxide equivalent), then there is an endpoint misalignment between the corrected coordinate segment [80, 89.6] and the suspended segment [80, 88]. The portion of the corrected coordinate segment that exceeds the endpoint 88 of the suspended segment [88, 89.6] needs to be re-aggregated at the endpoint boundary and divided into a new minimum verification segment [88, 89.6] through sub-steps 4.1 to 4.5, and the inherited bit is set for this new minimum verification segment; the portion within the endpoint 88 of the suspended segment is cleared and the inherited bit is set as usual in sub-step 7.3.

[0136] Through the above technical solution, this embodiment extracts the stage nodes and missing stage events corresponding to the suspended fragments and transforms the correction event data into correction coordinate segments according to the caliber mapping. Then, it clears the unverified bits of the minimum verification segment in the endpoint alignment manner and sets the inheritance bits or claim bits according to the correction source. Unlike the processing method of keeping suspended fragments on the books for a long time and relying on external manual reminders and post-event revisions, this embodiment provides an executable closed-loop path from suspended fragments to reconciled fragments at the data structure level. The updated fragment overlay code output is directly used as the criterion for remarking the conflict, suspended, and writable three states in step S6 and for continuing to accept subsequent registration requests in step S7.

[0137] See Figure 2 As shown, this solution proposes a highway carbon trading registration system based on a road material claiming and transfer chain, used to implement the aforementioned highway carbon trading registration method based on a road material claiming and transfer chain, including:

[0138] The data acquisition module is used to acquire material flow collection data, carbon quota claim data and caliber mapping data. The material flow collection data includes batch identifiers and measurement values. The carbon quota claim data includes claimed carbon quotas, registration calibers and compliance periods. The caliber mapping data includes measurement values ​​and the transformation relationship between claimed carbon quotas and numerical boundaries.

[0139] The merging and chain building module is used to merge material flow collection data by batch identifier to generate batch stage sequences, and to build a transfer chain data structure with stage sequence as nodes and stage time sequence as directed edges.

[0140] The coordinate transformation module is used to transform the measurement values ​​of the stage nodes into the receiving coordinate segments located by the registration dimension and numerical boundary based on the caliber mapping data. The registration dimension is obtained from the registration caliber and compliance period.

[0141] The chain-derived module is used to transform the upstream receiving coordinate segments into the downstream inherited coordinate segments along the data structure of the transfer chain, transform the claimed carbon amount into the claimed coordinate segments under the same registration dimension, and transform the missing stage events in the batch stage sequence into coordinate segments to be verified.

[0142] The segmentation mask module is used to extract the endpoint boundaries of inherited coordinate segments, claimed coordinate segments, and coordinate segments to be verified and segment them into minimum verification segments. It configures a multi-bit mask for each minimum verification segment and performs bit-setting operations on the inherited bits, claimed bits, and to-be-verified bits in the mask according to the type of the coordinate segment it hits to form a segment overlay code.

[0143] The fragment marking module is used to mark the smallest parity segment as a conflicting fragment, a hanging fragment, or a writable fragment based on the setting status of the inherited bit, the claim bit, and the unverified bit in the fragment coverage code.

[0144] The request processing module is used to obtain the requested carbon amount in the registration request, transform the requested carbon amount into a requested coordinate segment and align it with the minimum verification segment, read the segment coverage code covered by the requested coordinate segment, extract the overlapping sub-segments marked as writable segments as write segments, perform bit update on the segment coverage code corresponding to the write segment, and output the verification credentials containing the write segment, conflict segment, hanging segment and corresponding stage node.

[0145] In another embodiment, a computer device is 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 embodiments.

[0146] In one embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps described above.

[0147] In one embodiment, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and executes the computer instructions, causing the computer device to perform the steps described above.

[0148] The technical scope of this invention is not limited to the content described above. Those skilled in the art can make various modifications and variations to the above embodiments without departing from the technical concept of this invention, and all such modifications and variations should fall within the protection scope of this invention.

Claims

1. A method for registering a highway carbon transaction based on a road material claim transfer chain, characterized by, The method includes: Acquire material flow collection data, carbon quota claim data, and caliber mapping data. The material flow collection data includes batch identifiers and measurement values. The carbon quota claim data includes claimed carbon quotas, registration calibers, and compliance periods. The caliber mapping data includes measurement values ​​and the transformation relationship between claimed carbon quotas and numerical boundaries. The material flow data is aggregated according to the batch identifier to generate a batch stage sequence, and a transfer chain data structure is constructed with the stage sequence as the node and the stage time sequence as the directed edge. Based on the caliber mapping data, the measurement values ​​of the stage nodes are transformed into the connecting coordinate segments located by the registration dimension and numerical boundary. The registration dimension is obtained from the registration caliber and the compliance period. The upstream receiving coordinate segments are cumulatively transformed into downstream inherited coordinate segments along the data structure of the transfer chain, the claimed carbon quota is transformed into the claimed coordinate segments under the same registration dimension, and the missing stage events in the batch stage sequence are transformed into coordinate segments to be verified. Extract the endpoint boundaries of the inherited coordinate segment, the claimed coordinate segment, and the coordinate segment to be verified, and divide them into minimum verification segments. Configure a multi-bit mask for each minimum verification segment. Perform bit setting operations on the inherited bit, claimed bit, and to be verified bit in the mask according to the type of the coordinate segment to which it is hit to form a segment overlay code. Based on the setting status of the inheritance bit, claim bit, and unverified bit in the fragment overlay code, the minimum check segment is marked as a conflicting segment, a hanging segment, or a writable segment. Obtain the requested carbon amount from the registration request, transform the requested carbon amount into a requested coordinate segment and align it with the minimum verification segment, read the segment coverage code covered by the requested coordinate segment, extract the overlapping sub-segments marked as writable segments as write segments, perform bit update on the segment coverage code corresponding to the write segment, and output the verification credentials containing the write segment, conflicting segment, hanging segment and corresponding stage node.

2. The method according to claim 1, characterized in that, Before generating batch stage sequences by merging material flow collection data according to batch identifiers, event normalization processing is also included, specifically: Extract batch identifiers, measurement values, collection times, and stage types from material circulation data, and unify the batch identifier format, measurement unit, collection time format, and stage type name according to preset field mapping relationships; Under the same batch identifier, duplicate events are identified based on the collection time and stage type, and the event with the highest field completeness is retained as the standardized stage event; The events of the standardized phases are rearranged according to the collection time point, and the phase sequence is generated based on the changes in the phase type after rearrangement. Canonical stage events that cannot form a continuous stage sequence with the preceding and following stages are marked as missing stage events, and the missing stage events are written into the batch stage sequence under the corresponding batch identifier.

3. The method according to claim 1, characterized in that, Based on the caliber mapping data, the measurement values ​​of the stage nodes are transformed into connecting coordinate segments located by the registered dimension and numerical boundaries, specifically including: Based on the stage type corresponding to the stage node, read the caliber mapping entries that match the registration caliber and compliance period from the caliber mapping data; Based on the caliber mapping entries, the measurement values ​​of the stage nodes are transformed into the starting and ending numerical boundaries under the same registration dimension. The starting and ending numerical boundaries are encapsulated into receiving coordinate segments in numerical order, and the receiving coordinate segments are associated with the corresponding stage nodes. When there are multiple registration dimensions at the same stage node, the receiving coordinate segments under each registration dimension are generated respectively, and each receiving coordinate segment participates in the cumulative transformation of the subsequent inherited coordinate segments.

4. The method according to claim 1, characterized in that, Configure a multi-bit mask for each minimum check segment, and perform bit-setting operations on the inherited bits, claim bits, and unverified bits in the mask according to the type of the coordinate segment to be hit, to form a segment overlay code, specifically including: Under the same registration dimension, the starting and ending endpoint boundaries of inherited coordinate segments, claimed coordinate segments, and coordinate segments to be verified are aggregated to form an endpoint boundary set; The set of endpoint boundaries is deduplicated and numerically sorted, and the range between adjacent endpoint boundaries is divided into the smallest verification segment; Configure a multi-bit mask containing inheritance bits, claim bits, and unverified bits for each minimum check segment, and initialize each covered bit of the multi-bit mask to an unset state; Each minimum check segment is matched with the inherited coordinate segment, the claimed coordinate segment, and the coordinate segment to be verified. The minimum check segment that is completely covered by the corresponding coordinate segment performs a bit setting operation on the corresponding covering bit. The multi-bit mask after the bit setting operation is determined as the fragment overlay code, and the fragment overlay code is associated with and stored with the corresponding minimum parity segment.

5. The method according to claim 1, characterized in that, After constructing the transition chain data structure with stage sequence as nodes and stage time sequence as directed edges, the process also includes genealogical expansion processing for batch splitting, batch merging, and mixed events, specifically including: In the batch stage sequence, identify event combinations where there is a splitting of measurement values, a merging of measurement values, or mixing of different batches at the same stage position, and determine the batch splitting event, batch merging event, or mixing event based on the event combination; Based on the source batch identifier and destination batch identifier in the batch splitting event, batch merging event, or mixed event, generate parent batch nodes, child batch nodes, and phylogenetic directed edges connecting the parent batch nodes and child batch nodes. Based on the proportion of measurement values ​​or project affiliation corresponding to the source batch identifier and destination batch identifier, the contribution weight of the directed edge of the spectrum is generated. Perform boundary segmentation on the receiving coordinate segment of the parent batch node according to the contribution weight, or perform boundary merging on the receiving coordinate segments of multiple parent batch nodes to generate the receiving coordinate segment of the child batch node. Write the directed edges of the spectrum, contribution weights, and the receiving coordinate segments of the sub-batch nodes into the receiving chain data structure, and enable the receiving coordinate segments of the sub-batch nodes to continue to participate in the minimum check segment segmentation and fragment cover code generation.

6. The method according to claim 4, characterized in that, After transforming missing stage events in the batch stage sequence into coordinate segments to be verified, the process also includes cross-chain alignment for recycling and reusing reflows, specifically including: Identify recirculation events from batch stage sequences where old material batches are recycled and reused to enter the production stage of new material batches in building materials; Based on the old material batch identifier, new material batch identifier, and return measurement value corresponding to the return event, establish a cross-chain directed edge between the old material batch transfer chain data structure and the new material batch transfer chain data structure. Read the receiving coordinate segment and fragment coverage code of the old material batch recycling and reuse stage along the cross-chain directed edge, and transform the receiving coordinate segment into the return mapping coordinate segment of the new material batch building material production stage according to the caliber mapping data. The endpoint boundaries of the return mapping coordinate segment are incorporated into the endpoint boundary set of the new material batch building material production stage, and the minimum verification segment affected by the newly added endpoint boundaries is re-segmented. Based on the bit setting status of the fragment coverage code in the old material batch recycling and reuse stage, the inherited bit or the bit to be verified position is executed on the minimum verification segment of the new material batch covered by the reflow mapping coordinate segment.

7. The method according to claim 1, characterized in that, Based on the set states of the inheritance bit, claim bit, and unverified bit in the fragment overlay code, after marking the minimum parity segment as a conflicting segment, a hanging segment, or a writable segment, the process also includes correction processing for hanging segments, specifically including: Extract the stage node, registration dimension, endpoint boundary, and fragment coverage code corresponding to the suspended fragment, and retrieve the corresponding missing stage event based on the stage node; Obtain correction event data that matches the missing stage events, and transform the measurement values ​​or claimed carbon quotas in the correction event data into correction coordinate segments under the same registration dimension based on the caliber mapping data; Align the endpoints of the corrected coordinate segment with the minimum verification segment corresponding to the suspended segment, clear the unverified bits of the minimum verification segment covered by the corrected coordinate segment, and set the inheritance bit or claim bit according to the source type of the corrected event data. Re-mark conflicting, dangling, or writable segments corresponding to the minimum parity segment based on the updated segment overlay code.

8. A highway carbon trading registration system based on a road material requisition and transfer chain, characterized in that, A method for implementing a highway carbon trading registration system based on a road material claim-transfer chain as described in any one of claims 1-7, comprising: The data acquisition module is used to acquire material flow collection data, carbon quota claim data and caliber mapping data. The material flow collection data includes batch identifiers and measurement values. The carbon quota claim data includes claimed carbon quotas, registration calibers and compliance periods. The caliber mapping data includes measurement values ​​and the transformation relationship between claimed carbon quotas and numerical boundaries. The merging and chain building module is used to merge material flow collection data by batch identifier to generate batch stage sequences, and to build a transfer chain data structure with stage sequence as nodes and stage time sequence as directed edges. The coordinate transformation module is used to transform the measurement values ​​of the stage nodes into the receiving coordinate segments located by the registration dimension and numerical boundary based on the caliber mapping data. The registration dimension is obtained from the registration caliber and compliance period. The chain-derived module is used to transform the upstream receiving coordinate segments into the downstream inherited coordinate segments along the data structure of the transfer chain, transform the claimed carbon amount into the claimed coordinate segments under the same registration dimension, and transform the missing stage events in the batch stage sequence into coordinate segments to be verified. The segmentation mask module is used to extract the endpoint boundaries of inherited coordinate segments, claimed coordinate segments, and coordinate segments to be verified and segment them into minimum verification segments. It configures a multi-bit mask for each minimum verification segment and performs bit-setting operations on the inherited bits, claimed bits, and to-be-verified bits in the mask according to the type of the coordinate segment it hits to form a segment overlay code. The fragment marking module is used to mark the smallest parity segment as a conflicting fragment, a hanging fragment, or a writable fragment based on the setting status of the inherited bit, the claim bit, and the unverified bit in the fragment coverage code. The request processing module is used to obtain the requested carbon amount in the registration request, transform the requested carbon amount into a requested coordinate segment and align it with the minimum verification segment, read the segment coverage code covered by the requested coordinate segment, extract the overlapping sub-segments marked as writable segments as write segments, perform bit update on the segment coverage code corresponding to the write segment, and output the verification credentials containing the write segment, conflict segment, hanging segment and corresponding stage node.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method described in any one of claims 1-7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-7.

Images