Composite twin body construction method based on digital twinning, carbon emission and carbon sink acquisition method, monitoring system and readable storage medium

Abstract

The application relates to a composite twin body construction method based on digital twinning, a carbon emission and carbon sink acquisition method, a monitoring system and a readable storage medium. First, a meta-model library of classification levels is constructed, standardized access of multi-source data is realized through a unified parameter interface, an independent calculation model library is established, and factor values are dynamically called through a standardized interface; then, a twin body instance is generated based on the meta-model, an assembly edge is generated based on spatial topology analysis, a composite twin body graph structure taking the twin body instance as a node and the assembly edge as a connection is constructed; then, the twin body instance responds to an accounting request to call a calculation model to obtain carbon emission and carbon sink data of each twin body instance, and supports multi-dimensional summary statistics based on spatial location, meta-model classification levels and extended attributes, and realizes dynamic monitoring and early warning. The application realizes standardized modeling of urban entities from a micro perspective to a macro perspective and multi-scale carbon flow tracking.

Description

Technical Field

[0001] This invention relates to the field of digital twin and carbon emission and carbon sink monitoring technology, and in particular to a method for constructing a composite digital twin, a method for acquiring carbon emission and carbon sink data, a monitoring system, and a readable storage medium. Background Technology

[0002] Cities, as complex entities possessing administrative, geographical, economic, and socio-cultural attributes, are key units for carbon emissions and carbon sinks, and crucial levers for achieving carbon reduction targets. However, current carbon emission and carbon sink work primarily focuses on micro-level accounting, lacking monitoring and early warning at the macro-level, such as at the city level. Specific problems include:

[0003] 1) Carbon management in various industries, regions and fields in the city is fragmented. Forestry, industry, transportation, construction and other industries carry out carbon emission or carbon sink monitoring separately and the data is not shared. This results in fragmented carbon emission and carbon sink data with poor correlation, which cannot reflect the comprehensive carbon emission or carbon sink level of a region and cannot fully reflect the overall situation of the city's carbon balance sheet.

[0004] 2) Existing technologies mostly focus on static monitoring or calculation in a single dimension, lacking the integration of information such as population flow, traffic flow changes, and energy consumption trends. They cannot achieve dynamic tracking of carbon emissions and carbon sinks, and are even less able to support urban planning optimization, implementation of emission reduction measures, and accurate prediction and early warning of carbon emissions and carbon sinks.

[0005] 3) The application of existing digital twin technology in the field of ecological and environmental protection still faces bottlenecks such as difficulty in data fusion, complexity in model construction, and low standardization. Moreover, most applications are concentrated at the park level and cannot meet the multi-granularity and multi-dimensional carbon management needs at the city level.

[0006] Currently, Sun Baodi et al. published "Real Needs, Development Trends and Future Prospects of Digital Twin Technology Empowering Community-Scale Carbon Accounting" in the Journal of Geoinformation Science (2025, Vol. 27). They proposed a digital twin technology suitable for community carbon accounting that combines Building Information Modeling (BIM), Geographic Information System (GIS), Internet of Things (IoT) and Artificial Intelligence (AI). They also mentioned that the City Information Modeling (CIM) platform integrating BIM, GIS and IoT technologies has become an important direction for future development. However, the core scale they focus on is still the community level, and they lack more macro-level monitoring, management and specific practical methods for carbon flow across the entire city.

[0007] Chinese invention patent CN121032755A discloses a method for a city-level digital twin cloud management platform supporting multi-scenario access. This method comprises a platform system consisting of six modules: multi-dimensional modeling, risk analysis, operation and maintenance decision-making, evaluation and optimization, global optimization, and cloud management. It uses infrastructure, transportation, and energy as the three core scenarios, achieving adaptive cloud management of urban risks through end-to-end digitalization and algorithm optimization. However, this method does not consider carbon sink-related scenarios, nor does it further subdivide the three macro-level scenarios. This results in data fusion across different scenarios remaining at the macro level, and it fails to consider twin updates caused by urban development, leading to poor scalability.

[0008] Chinese invention patent CN121146214A discloses a method and system for intelligent decision-making assistance in carbon emission reduction. This method utilizes three-dimensional air-space-ground perception, multi-driven carbon twin modeling, intelligent agent alliance collaborative optimization and decision-making, and cost-adaptive calibration to transform carbon emission reduction management from passive response to proactive optimization, focusing on the intelligent management needs of carbon emission reduction in various scenarios such as industry, construction, and transportation. However, this method uses a regional and scenario-based approach, failing to precisely characterize the features of different functional units within a city; data collection employs a scenario-customized model, making rapid parameter integration and reuse difficult, resulting in high costs for scenario expansion. Summary of the Invention

[0009] The purpose of this invention is to provide a method for constructing a composite twin based on digital twins, a method for acquiring carbon emissions and carbon sinks, a monitoring system, and a readable storage medium, so as to overcome the defects of low standardization of digital twin modeling, static maintenance of spatial relationships, and tight coupling between carbon emission and carbon sink accounting and physical models in the prior art, and realize the standardized fusion of city-level multi-source data, dynamic assembly of composite twins, and full-chain traceability of carbon emission and carbon sink data.

[0010] To achieve the above objectives, in a first aspect, the present invention provides a method for constructing a composite twin based on digital twins, comprising:

[0011] A meta-model library is constructed based on a preset classification hierarchy. The classification hierarchy includes at least the top-level technology domain category and the bottom-level technology attribute type. Physical entities are abstracted into meta-models according to the technology attribute type. The meta-model is configured with a unified parameter interface.

[0012] Construct a carbon emission and carbon sink calculation model library independent of the meta-model library. The carbon emission and carbon sink calculation model library is associated with the meta-model library through a standardized interface to support independent iteration and version management of the calculation logic.

[0013] Collect and clean multi-source data, verify the cleaned data based on the meta-model, and generate a twin instance carrying a unique twin ID and the corresponding meta-model version number based on the meta-model; the twin instance encapsulates static and dynamic parameters and inherits the computational logic identifier associated with its meta-model.

[0014] Based on the static parameters of each twin instance and the preset assembly rules, spatial topology analysis is performed to generate assembly edges, and the composite twin is constructed from multiple twin instances and the assembly edges.

[0015] Optionally, the step of generating the twin instance includes:

[0016] Listen to the message queue to obtain the cleaned data, which includes the metamodel ID and version number;

[0017] Call the parameter interface of the meta-model library to obtain the corresponding version of JSON Schema, verify the cleaned data, and transfer the data that fails the verification to the abnormal data pool;

[0018] The verified data is matched against instances based on a unique business identifier or spatial location, wherein the unique business identifier has a higher priority than the spatial location.

[0019] If a match is successful, the static parameters are merged and the time-series data of the dynamic parameters are appended; if a match fails, a new unique twin ID is generated to create an instance.

[0020] Optionally, for the data that passes the verification, the following further information may be included:

[0021] The static parameters are written to the twin instance table in UPSERT mode, and the dynamic parameters are batch appended to the dynamic parameter time series table. The duplicates are removed by combining the unique twin ID of the twin instance with the timestamp. Among multiple data with the same timestamp, the last one is retained.

[0022] The update of the static parameters and the writing of the dynamic parameters adopt an eventual consistency model. First, the twin instance table is updated, and then the dynamic parameters are appended to the dynamic parameter timing table. The version snapshot before the change corresponding to each update operation of the static parameters is recorded through an audit table.

[0023] During the execution of the static parameter writing or the dynamic parameter writing operation, an exponential backoff retry strategy is adopted for temporary errors of database connection failure. After a retry fails, the error is written to a dead letter queue for offline compensation.

[0024] Optionally, the preset assembly rules define multiple spatial relationship types and corresponding spatial predicates based on the static parameters of each twin instance. The spatial relationship types include at least: co-position assembly based on ST_Intersects, containment assembly based on ST_Covers, adjacency assembly based on ST_Touches, traversal assembly based on ST_Crosses, and distance-constrained assembly based on ST_DWithin with a distance threshold configured.

[0025] Optionally, the spatial topology analysis employs a two-stage process combining coarse screening and fine judgment:

[0026] First, based on the distance thresholds corresponding to all distance class rules, a coarse screening is performed using the ST_DWithin predicate to select candidate twin pairs;

[0027] Subsequently, according to the preset spatial matching priority, the corresponding spatial predicates are called in sequence to perform fine-grained judgment on the candidate twin pairs. The spatial matching priority is: contain > traverse > adjacency assembly > distance constraint assembly > co-position assembly. Once a match is successful, the subsequent judgment is stopped and the assembly edge is established.

[0028] Optionally, the assembly relationship of the twin instances is maintained through a change capture and incremental update mechanism, specifically including:

[0029] Listen for changes to the geometry field, technology domain category, or metamodel ID of the twin instance using triggers;

[0030] Take the union of the old and new geometric buffers as the scope of influence, and delete the old relations that have become invalid within the scope of influence;

[0031] Traverse the candidate twin pairs within the influence range, re-determine the new relationship according to the spatial matching priority, and insert it;

[0032] By using a timed task to compare the current spatial positional relationship with existing relationship records, invalid relationships are marked and repaired.

[0033] Optionally, the composite twin is a graph structure with the twin instance as nodes and the assembled edge as connecting edge; the edge features of the assembled edge include relation type encoding and distance value.

[0034] Secondly, the present invention also provides a method for obtaining carbon emissions and carbon sinks based on a composite twin, wherein the composite twin is constructed based on the composite twin construction method based on digital twins as described above, and includes the following steps:

[0035] In response to the accounting request, read the static and dynamic parameters of each twin instance in the composite twin;

[0036] Based on the computational logic identifier inherited by each twin instance, the corresponding version of the computational logic in the carbon emission and carbon sink computational model library is invoked;

[0037] The static and dynamic parameters are substituted into the calculation logic for processing to obtain carbon emission and carbon sink data for each twin instance.

[0038] Thirdly, the present invention also provides a carbon emission and carbon sink monitoring system, comprising:

[0039] The data processing layer is configured to collect multi-source data, perform standardized cleaning, and encapsulate it into a data stream that conforms to the meta-model specification;

[0040] The twin layer includes a meta-model library, a twin instance generation module, and a twin assembly module; among them,

[0041] The meta-model library is configured to be built based on a preset classification hierarchy. The classification hierarchy includes at least the top-level technology domain category and the bottom-level technology attribute type. Physical entities are abstracted into meta-models according to the technology attribute type. The meta-model is configured with a unified parameter interface.

[0042] The twin instance generation module is configured to verify the cleaned data based on the meta-model, and generate a twin instance carrying a unique twin ID and a corresponding meta-model version number based on the meta-model. The twin instance encapsulates static parameters and dynamic parameters, and inherits the computational logic identifier associated with its meta-model.

[0043] The twin assembly module is configured to perform spatial topology analysis based on the static parameters of each twin instance and preset assembly rules, generate assembly edges, and construct a composite twin from multiple twin instances and the assembly edges.

[0044] The computational layer includes a carbon emission and carbon sink calculation model library and a carbon emission and carbon sink calculation module. The carbon emission and carbon sink calculation model library includes independently stored formula and factor libraries; wherein,

[0045] The formula library is configured with predefined standardized interfaces to dynamically call factor values ​​from the factor library;

[0046] The carbon emission and carbon sink calculation module is configured to respond to a calculation request by calling the calculation logic in the formula library and the factor values ​​in the factor library to perform carbon emission and carbon sink calculation.

[0047] The carbon emission and carbon sink calculation model library is decoupled from the meta-models stored in the meta-model library.

[0048] Fourthly, the present invention also provides a readable storage medium having a computer program stored thereon, wherein the computer program, when executed, can implement the method for constructing a composite twin based on digital twins as described above, and the method for obtaining carbon emissions and carbon sinks based on composite twins as described above.

[0049] The method for constructing a composite digital twin, the method for acquiring carbon emissions and carbon sinks, the monitoring system, and the readable storage medium based on digital twins provided by this invention have at least one of the following beneficial effects:

[0050] (1) Through a predefined meta-model library with a unified parameter interface, various physical entities such as buildings, facilities, and green spaces in the city can be forcibly mapped into structured data objects in the digital space, eliminating the arbitrariness and heterogeneity of entity information description in the natural world and achieving 100% standardized coverage.

[0051] (2) By generating and assembling twin instances, discrete twins are flexibly arranged and associated in space according to their geographical attributes, and a cluster model composed of digital twin units with correct spatial adjacency and inclusion relationships between units is automatically output. At the same time, it maintains good scalability and can quickly respond to twin updates and changes.

[0052] (3) By decoupling the carbon emission and carbon sink calculation rule library, carbon emission and carbon sink calculation module and meta-model, twin instance related modules, the calculation rules can be maintained and managed separately. This fundamentally avoids the difference in calculation results caused by decentralized definition or temporary modification, ensuring the comparability of carbon emission and carbon sink data, while ensuring the flexible iteration and secure release of carbon emission and carbon sink rules.

[0053] (4) Based on the data information of twin instances, the free combination and cross-statistics of three dimensions—spatial location, meta-model level, and extended attributes—are realized to achieve multi-dimensional analysis and monitoring and early warning of carbon emission and carbon sink data, and to flexibly adapt to diverse statistical needs such as higher-level planning, zoning management, and industry supervision. Attached Figure Description

[0054] Those skilled in the art will understand that the accompanying drawings are provided to better understand the invention and do not constitute any limitation on the scope of the invention. Wherein:

[0055] Figure 1 A flowchart illustrating a method for constructing a composite twin based on digital twins according to an embodiment of the present invention;

[0056] Figure 2 This is a business architecture diagram of a carbon emission and carbon sink monitoring system provided in an embodiment of the present invention;

[0057] Figure 3 This is a structural block diagram of a carbon emission and carbon sink monitoring system provided in an embodiment of the present invention. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0059] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0060] In the description of this invention, it should be understood that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship commonly used when the product is in use, or the orientation or positional relationship commonly understood by those skilled in the art. They are only used to facilitate the description of this invention and to simplify the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0061] Furthermore, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such an article or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the article or apparatus that includes said element. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0062] Please refer to Figure 1 This invention provides a method for constructing a composite twin based on digital twins, comprising the following steps:

[0063] S1. Construct a meta-model library based on a preset classification hierarchy. The classification hierarchy includes at least the top-level technical domain category and the bottom-level technical attribute type. Abstract physical entities into meta-models according to the technical attribute types. Configure a unified parameter interface for the meta-model.

[0064] S2. Construct a carbon emission and carbon sink calculation model library independent of the meta-model library. The carbon emission and carbon sink calculation model library is associated with the meta-model library through a standardized interface to support independent iteration and version management of the calculation logic.

[0065] S3. Collect and clean multi-source data, verify the cleaned data based on the meta-model, and generate a twin instance carrying a unique twin ID and the corresponding meta-model version number based on the meta-model; the twin instance encapsulates static and dynamic parameters and inherits the computational logic identifier associated with its meta-model.

[0066] S4. Based on the static parameters of each twin instance and the preset assembly rules, perform spatial topology analysis to generate assembly edges, and construct the composite twin from multiple twin instances and the assembly edges.

[0067] By abstracting complex urban entities into standardized models of a limited number of types with unified parameter interfaces through a meta-model library, its pre-defined geographic and activity data interfaces ensure that any entity adheres to the same data specifications when accessing the system. This fundamentally solves the long-standing problems of data heterogeneity and system silos in the field of digital twins. Furthermore, model-based abstraction transforms the digital construction process of a city into an assembly logic. Through twin assembly, twins can be instantiated and combined based on real geographic information of any region, rapidly generating well-structured multi-scale models ranging from micro-industry levels to macro-city levels. Additionally, the meta-model's activity data interface is designed to proactively consider the needs of carbon emission and carbon sink calculations, making data streams directly related to carbon emission and carbon sink calculations, such as energy consumption and production capacity, inherent attributes of the model rather than post-hoc analytical items. This lays an unshakeable foundation for end-to-end, traceable carbon management.

[0068] It should be noted that the "digital twin" mentioned in this invention refers to the real-time mapping of a physical entity (such as equipment, system, or process) in virtual space using data, models, and simulation technologies, for simulating, analyzing, predicting, and controlling its entire lifecycle behavior. A "twin" refers to a virtual digital model in digital twin technology that corresponds one-to-one with a physical entity and interacts in real time, capable of simulating, mapping, and reflecting the state, behavior, and changes of its physical object. "Carbon emissions" is short for carbon dioxide emissions, referring to the behavior or total amount of carbon dioxide released into the atmosphere by human activities (such as fossil fuel combustion, industrial production, transportation, etc.) or natural processes; it is a key indicator for measuring the impact of greenhouse gases. "Carbon sinks" refer to the processes, activities, or carriers that absorb and store carbon dioxide in the atmosphere through natural ecosystems (such as forests, oceans, wetlands, and soil) or artificial means; they are a key mechanism for reducing atmospheric greenhouse gas concentrations.

[0069] First, S1 is executed to construct a metamodel library. This library, by defining finite types of "technical attribute templates," reduces an infinite number of physical entities to a finite set of parameterized descriptions with unified technical definitions. This system is built upon a pre-defined classification hierarchy, with the top level fixed as the technical domain category, representing the basic technical system type to which the entity belongs. This category is divided into five dimensions: buildings, facilities, roads, green spaces, and others. The metamodel only performs instantiation at the lowest level, the technical attribute type level. This level contains complete technical parameter descriptions, including static and dynamic parameters—technical features that can be directly mapped to specific instances—and is the smallest granular unit for data acquisition and model generation. Classification nodes at non-technical attribute type levels serve as logical grouping identifiers, existing only as string encodings. Information from higher levels serves as context identifiers for attribute inheritance and does not participate in model instantiation, but it supports aggregation calculations of instance data based on classification nodes at each level.

[0070] In this embodiment, the preset classification hierarchy preferably adopts a three-level hierarchical structure: the first level defines the technical domain category of the entity; the second level defines the functional role of the entity, representing the functional positioning of the entity in the technical system; and the third level defines the technical attribute type of the entity. In other variant implementations, the number of levels can be expanded to four or reduced to two, but must satisfy the following: the top level must be a technical domain category (limited to the five categories listed in Table 1), the bottom level must be a directly instantiable technical attribute type, and the functional positioning of the intermediate levels follows the constraint of "the upper and lower levels are in an inclusive relationship".

[0071] Examples of the technical attributes of common entities are shown in Table 1 below.

[0072] Table 1

[0073]

[0074]

[0075] In this embodiment, PostgreSQL+JSONB is used as the storage engine for the metamodel definition. The metamodel definition template is stored in JSONB and includes static parameters, dynamic parameters, and applicable calculation processes. The parameters are defined using JSON Schema and semantic tags to ensure machine readability, verifiability, and scalability. Each metamodel ID and version combination uniquely identifies a metamodel version, and a status field identifies the currently recommended version. Here, the call contract for obtaining the JSON Schema provided by the metamodel definition template constitutes the parameter interface of the metamodel described in this invention.

[0076] To implement the above storage scheme, the storage structure of the metamodel is organized using relational database tables. The fields contained in the metamodel table are shown in Table 2, and none of them are allowed to be empty.

[0077] Table 2

[0078]

[0079] The following explanation uses the metamodel of a high-rise building as an example. This metamodel is named "High-Rise Residential Building," with the metamodel ID "BLD_RES_HIGH," the parent ID "BLD_RES," a level of 3, and a geometry type limited to polygons or polygon sets. The model definition of this metamodel is described using the JSON Schema specification, and the specific parameters are shown in Table 3.

[0080] Table 3

[0081]

[0082] It is understood that the above-described high-rise residential building metamodel is merely a specific example of the metamodel definition template of this invention. In practical applications, corresponding metamodel definition templates can be constructed according to different entity object types. Each template adopts the same JSON Schema definition structure and parameter grouping method, with only the specific parameter items, data types, units of measurement, and value ranges within each group adjusted according to the different object types. Based on the example of the above-described high-rise residential building metamodel, those skilled in the art can apply the metamodel definition template of this invention to other types of entity objects without any inventive effort.

[0083] In this embodiment, a "semantic versioning + multiple version coexistence" strategy is adopted for metamodel version management. When there are incompatible structural changes, such as deleting fields or modifying field types, the major version number is updated; if it is only a backward-compatible functional extension, such as adding optional fields, the minor version number is updated; if it is only a descriptive modification, such as comments or unit adjustments, the revision number is updated. Multiple versions are allowed under a single metamodel ID, but only one version can be active at any given time (i.e., its usage status is TRUE). When a new version is created, its default usage status is FALSE. After administrator confirmation and release, the old version's usage status is set to FALSE, and the new version is set to TRUE. The old version is still retained in the table for historical twin instance retrospective use. When releasing a new version, the system verifies its compatibility with the old version. If it is an upgrade to the major version, the system checks running tasks via the message queue to ensure that no active twin instance is currently using the old version; otherwise, the release is blocked and manual intervention is required. If it is an upgrade to a minor version or revision number, it is automatically approved.

[0084] Then, S2 is executed to construct a carbon emission and carbon sink calculation model library that is independent of the meta-model library. The carbon emission and carbon sink calculation model library is associated with the meta-model library through a standardized interface to support independent iteration and version management of the calculation logic.

[0085] In this embodiment, the carbon emission and carbon sink calculation model library, through decoupling design, separates the calculation logic from the twin structure and application scenarios, achieving centralized management, unified invocation, and flexible evolution of the carbon emission and carbon sink calculation model. Simultaneously, it ensures that the same type of twin uses consistent calculation methods in different regions and at different times, avoiding logical inconsistencies. The carbon emission and carbon sink calculation model library is internally divided into a formula library and a factor library, both supporting versioned storage. Calculation rules or factors can be updated without modifying the twin instance, and historical backtracking is supported.

[0086] The factor library stores various carbon emission and carbon sink factors and related parameters, supporting multi-dimensional version management. These dimensions include at least regional and time dimensions, and may also include a technology type dimension. The factor library uses PostgreSQL relational tables with valid time intervals for storage. Each factor table represents a type of parameter (such as electricity emission factors, biomass expansion factors, etc.). The common fields included in each factor table are shown in Table 4. Except for the technology type and expiration date fields, all other fields are not allowed to be empty.

[0087] Table 4

[0088]

[0089] For carbon emission and carbon sink factors that do not include technology types, a combination of factor code, region, and version number is used as a unique identifier for each record, and a composite index is created on the factor code, region, and effective start and end date fields. This type of factor table uses exclusive constraints combined with a generalized B-tree index and date range type to convert the effective date and expiration date into continuous time intervals, ensuring that the effective time intervals of records under the same factor code and region do not overlap. Taking the electricity emission factor table as an example, the technology type field is empty, and its uniqueness constraint is determined by the factor code, region, and version number fields. Furthermore, at any given time, there is at most one valid electricity emission factor record under the same factor code and region, ensuring that the factor data is unambiguous in the time dimension.

[0090] For carbon emission and carbon sink factors that include technology types, a unique identifier for each record is a combination of factor code, region, technology type, and version number. A composite index is established on the factor code, region, technology type, and effective start and end date fields. Taking the biomass expansion factor table as an example, its technology type is specifically represented by the forest type field, used to distinguish the biomass expansion factor values ​​under different forest categories. The uniqueness constraint of this table is determined by the four fields: factor code, region, forest type, and version number. The coverage of its exclusivity constraint is correspondingly extended to ensure that the time intervals under the combination of factor code, region, and forest type do not overlap.

[0091] The query interface accepts factor code, technology type (None if no technology type is specified), region, and effective date as query parameters. It first searches the corresponding factor table for factor records that exactly match the specified region. If no exact match is found, it automatically falls back to coarser-grained region records (e.g., from provincial / municipal level to national level, and finally to the "GLOBAL" global default value). Based on the time interval (including endpoints) defined by the effective and expiration dates in the factor table, it automatically matches valid factor records within that time interval. If no match is found, it automatically matches the record with the closest effective date. Finally, it returns factor records that meet the above conditions. The semantic version number is returned as a record attribute and is not used as a query condition.

[0092] The formula library stores the calculation logic for different carbon emissions and carbon sinks. The calculation logic exists in the form of parsable expressions, and the required carbon emission and carbon sink factors are obtained by referencing the factor codes in the factor library. Formulas are stored using PostgreSQL+JSONB, and each formula is associated with a meta-model type. The fields contained in the formula table are shown in Table 5; except for parameter fields, none can be empty.

[0093] Table 5

[0094]

[0095] The expression engine executes calculation logic by parsing expression fields. Specifically, the expression obtains factor values ​​by calling the function `factor(factor code, region, calculation time, technology type)`, where `None` is passed if no technology type is specified. The factor code is explicitly written into the expression in the form of a `factor` function call and does not appear as an independent variable in the expression. The factor codes referenced by the formula are stored in the factor reference field, which can quickly locate affected formulas when factors are updated, triggering compatibility checks or cache invalidation. When factors are updated, the formula library does not need to be modified; only the version of the corresponding factor in the factor library needs to be updated. If the formula logic itself changes, a new version of the formula is created, and the old version's usage status is set to `FALSE`.

[0096] Taking the carbon emission formula for building operation as an example, its expression is: "electricity_consumption * (1 -pv_electricity_ratio) * factor('ELEC_CN', region, calc_date) + gas_consumption * factor('NGAS_CN', region, calc_date)". This means that the carbon emissions from building operation are equal to the daily electricity consumption multiplied by (1 minus the proportion of photovoltaic power generation) and then multiplied by the electricity emission factor (obtained through the factor function for the Chinese region), plus the daily gas consumption multiplied by the natural gas emission factor (obtained through the factor function for the Chinese region).

[0097] When the variable names in the formula and the field names in the factor table are inconsistent due to business requirements, the variable names are kept unchanged. A mapping logic is added to the factor library service layer to convert the variable names into the field names required by the factor table before querying. The mapping logic is maintained independently. Taking the calculation formula for forest carbon sink as an example, its expression is: "area * annual_growth * factor('BEF', dominant_species, calc_date) * factor('CF', dominant_species, calc_date) * factor('WD', dominant_species, calc_date)", indicating that the forest carbon sink is equal to the forest area multiplied by the annual volume growth, and then multiplied by the biomass expansion factor (BEF), carbon coefficient (CF), and timber density (WD) in sequence. The latter three are obtained through the factor function with forest type (forest_type) as the technical type dimension. It should be noted that, to better reflect the business description, the parameter name corresponding to the forest type in the static parameters of the sparse forest element model is "dominant_species". In the forest carbon sink formula, the dominant tree species variable is still used to maintain consistency with the meta-model parameters. The values ​​of the dominant tree species are converted into the forest type required by the factor table in the factor library service layer before querying.

[0098] It's important to note that the carbon emission and carbon sink calculation model library and the meta-model library have a strong dependency relationship. Variables referenced in formulas must be defined in the meta-model, and the meta-model ID to which the formula applies must correspond to a defined meta-model in the meta-model library. When creating a new formula, the carbon emission and carbon sink calculation model library retrieves the definition of the currently used meta-model (TRUE) by passing in the meta-model ID, and then parses the formula expression to extract all external variables. It's crucial to note that only ordinary identifiers in the expression are extracted, excluding factor calls and their internal parameters. Then, it verifies whether each variable is defined in the meta-model. If all variables are defined, the verification passes, and the formula can be saved; if undefined variables exist, manual handling is required.

[0099] After a new version of the metamodel library is released, the old version's usage status changes to FALSE but is retained. The metamodel library sends a metamodel change notification to the carbon emission and carbon sink calculation model library, carrying information about the old and new versions. Upon receiving the notification, the carbon emission and carbon sink calculation model library asynchronously triggers a compatibility check task, creating or adapting a new formula version for the new version of the metamodel, rather than modifying historical formulas. For historical calculations, since each twin instance records its metamodel version upon creation, the calculation engine strictly uses the formula version matching that metamodel version for calculations. For future calculations, upon receiving the notification, the carbon emission and carbon sink calculation model library will create a new formula record (version incremented) for the new metamodel version based on the new version's metamodel definition, and record its dependent metamodel versions. For formulas with a usage status of TRUE, the compatibility of their parameters with the new version of the metamodel is checked. If fully compatible, a new formula version pointing to the new metamodel version can be created; if incompatible, the formula is marked as "pending review," requiring manual intervention to adjust the logic.

[0100] The carbon emission and carbon sink calculation model library needs to cache commonly used formulas in memory using the key (metamodel ID, metamodel version, calculation process) to reduce database queries and ensure version isolation. Factor values ​​in the factor library are also cached using (factor code, region, technology type, effective date). Note that factors have start and end validity periods; the calculation date should be included as part of the key when caching to avoid returning expired factors. When a factor or formula is updated, the relevant cache should be precisely cleared via message notification to avoid a decrease in cache hit rate caused by a full clear. This decoupled design allows updates to the accounting rules to be made without modifying the twin instance; only the corresponding version in the carbon emission and carbon sink calculation model library needs to be adjusted, significantly reducing iteration costs.

[0101] Next, S3 is executed to collect and clean multi-source data. The cleaned data is verified based on the meta-model, and a twin instance carrying a unique twin ID and the corresponding meta-model version number is generated based on the meta-model. The twin instance encapsulates static and dynamic parameters and inherits the computational logic identifier associated with its meta-model.

[0102] In this embodiment, a data acquisition and cleaning module is used to collect and clean multi-source data. This data acquisition and cleaning module undertakes the functions of data acquisition, data standardization, and data quality assurance, providing a compliant, reliable, and computable data foundation for other modules.

[0103] The data acquisition module is designed based on the principle of minimum necessary data collection, configuring and collecting only the core business, spatial, and dynamic parameter fields required for carbon emission / carbon sink accounting and digital twin modeling. This module supports diverse data source access through configurable adapters, including government shared interfaces, enterprise energy consumption monitoring platforms, GIS services, BIM files, IoT middleware, and public data APIs. For various data sources, adapter-level compliance configurations are implemented. For example, for data accessed through official APIs, the adapter is configured with corresponding authentication tokens and access permissions; for file and database imports, the adapter verifies the data provider's authorization; the network data acquisition adapter supports configuring request frequency and UA identifier, and adheres to the target website's robots.txt protocol and terms of service. The module has a built-in data anonymization component that performs real-time anonymization or masking of identified non-essential fields such as personal identification information and sensitive business information before the data flows into the standardized cleaning process.

[0104] Different adapters and acquisition methods are used for different data sources. For example, the spatial data adapter supports reading and converting Shapefile / GeoJSON vector and GeoTIFF raster data, using the GDAL open-source library combined with a custom format parsing algorithm, and directly querying through ArcGIS REST API, WMS / WFS services, and PostGIS to obtain data such as building outlines, road centerlines, and land use classifications from the GIS platform; the BIM adapter parses IFC standard files (using IfcOpenShell, xBIM) or extracts parameters such as spatial location, number of floors, and building area through the BIM360 API; the streaming adapter supports real-time access to time-series data, supports multi-protocol conversion, and can obtain data such as electricity meter readings, temperature and humidity, traffic flow, and water quality monitoring through MQTT subscription, HTTP polling, and IoT platform APIs; the structured adapter can map by business fields, supports incremental synchronization, and can connect to relational databases and RESTful databases through JDBC. API calls and data sharing and exchange platforms are used to obtain data such as real estate registration, business registration, environmental monitoring, and population statistics. Network data adapters need to have the ability to handle anti-crawling, rate limiting, and data parsing. They should be able to counter anti-crawling strategies through dynamic UA spoofing and request frequency control, and extract valid data by combining regular expressions and DOM parsing technology. They can obtain data such as open map POIs, remote sensing images, and public statistical yearbooks through web crawlers, open APIs, and satellite data APIs.

[0105] Data acquisition employs a hybrid strategy of full and incremental data collection. The initial collection gathers all static data, while subsequent collections use timestamps or change logs to gather incremental data, minimizing resource consumption. Dynamic activity data is collected in real-time streaming, while static data is processed in batches on a scheduled basis. When the same parameter comes from multiple sources, a preset priority is used based on data accuracy, authority, and real-time performance: government data > IoT data > internet data.

[0106] The processing phase mainly includes verification, standardization, gap filling, and alignment steps. Real-time IoT data is processed using Apache Flink or Spark Streaming; static data is processed using Spark batch processing or Airflow scheduling. In this phase, the metamodel's verification interface is first called to verify whether each data item conforms to the field type, unit, required fields, and value range defined in the metamodel, checking spatial topology (e.g., building outlines should not overlap) and temporal data order (e.g., timestamps increment). Simultaneously, statistical methods (e.g., the 3σ rule) are used to identify values ​​outside the normal range, marking them as suspicious and requiring manual processing. Next, the PROJ library is used to transform all spatial data to a unified coordinate system, such as CGCS2000 or WGS84, ensuring accurate spatial assembly; based on the units defined in the metamodel, the original units are automatically converted, such as converting meters... 2 The process involves converting data fields to HA values, mapping original data field names to metamodel parameter names (e.g., converting `building_area` to `floor_area`), ensuring direct usability during instance generation. Next, missing values ​​are handled. For required parameters, manual processing is introduced; for optional parameters, missing values ​​can be filled using pre-set default values ​​(e.g., occupancy rate defaults to 0.8). Time-series data uses linear interpolation to fill in short-term missing points, while seasonal data uses seasonal decomposition interpolation. Finally, records describing the same physical entity from different data sources are linked based on property unit numbers, facility codes, etc. If no unified identifier exists, spatial matching can be used, such as point-to-area inclusion or buffer proximity, with PostGIS spatial indexing used to improve efficiency. Additionally, data with different frequencies needs to be interpolated to a unified time granularity (e.g., IoT minute-level and statistical monthly-level data are unified to daily data) for easier subsequent calculations.

[0107] The entire process records the source channels, collection time, meta-model version, adapter type, priority determination criteria, and cleaning and correction logs of various types of data, forming an immutable data traceability ledger; for anomaly identification and marking, and manual review of suspicious data, hierarchical access control and operation logging are set up to ensure that data governance behavior is transparent, compliant, auditable and traceable.

[0108] Considering that the metamodel only contains core parameters strongly related to carbon emission and carbon sink calculations, but the raw data may contain other useful information, such as additional fields like industry classification, these fields do not participate in carbon emission and carbon sink calculations but can be used for twin classification, scenario selection, and other scenarios. Therefore, this part of the data needs to be collected during the data acquisition phase. To store this information, an extended attribute JSONB field is added to the twin instance table to store the additional information in flat JSONB key-value pairs for easy on-demand querying.

[0109] The cleaned data is written to Kafka, including the metamodel ID, metamodel version, cleaned static parameters, dynamic parameters, extended attributes, and data source metadata, such as collection time and data source, for use in generating twin instances.

[0110] Then, based on the cleaned and standardized data, twin instances that conform to the meta-model definition are generated and persistently managed, providing unified data services for downstream applications such as twin assembly, carbon emission and carbon sink calculation and result visualization, and data association rule learning.

[0111] Furthermore, the step of generating the twin instance includes:

[0112] Listen to the message queue to obtain the cleaned data, which includes the metamodel ID and version number;

[0113] Call the parameter interface of the meta-model library to obtain the corresponding version of JSON Schema, validate the cleaned data, and transfer the data that fails the validation to the abnormal data pool;

[0114] The verified data is matched against instances based on a unique business identifier or spatial location, wherein the unique business identifier has a higher priority than the spatial location.

[0115] If a match is successful, the static parameters are merged and the time-series data of the dynamic parameters are appended; if a match fails, a new unique twin ID is generated to create an instance.

[0116] In this embodiment, data packets are obtained by listening to Kafka topics or reading batch files. These packets contain metamodel IDs, metamodel versions, static parameters, dynamic parameters, extended attributes, and data source metadata. The metamodel library's parameter interface is called based on the metamodel ID and version to obtain the complete JSON schema for the corresponding version. If no version is specified, the currently active version is used. The metamodel library's validation interface is called, passing in the metamodel ID, metamodel version, and the data to be validated, to obtain the validation result. Data that fails validation is entered into an exception data pool, and the reason for the error is recorded, allowing for manual correction and resubmission. Data that passes validation enters the instance matching process.

[0117] Instance matching is performed based on unique business identifiers such as property unit numbers and facility codes, or spatial locations. When multiple identifiers exist simultaneously, the matching result is determined by prioritizing the unique business identifier, followed by spatial location. If the match is successful, an update operation is performed, merging static parameters and appending dynamic parameter time-series data; if the match fails, a globally unique twin ID is generated to create a new instance. Static parameters are stored in the static parameter JSONB field and geometry field of the twin instance table; dynamic parameters are stored in the dynamic parameter time-series table; extended attributes are stored in the extended attribute JSONB field; and meta-information records include the meta-model ID and meta-model version.

[0118] During writing, static data is written to the twin instance table using the UPSERT method; dynamic data is batch-appended to the dynamic parameter time series table, deduplicated by a combination of twin ID and timestamp, retaining the last record when multiple records have the same timestamp. Static data updates and dynamic data writes employ an eventual consistency model, updating the main table first and then writing to the dynamic parameter time series table. For business scenarios with strong consistency requirements, Saga mode distributed transactions can be configured. Historical changes to static parameters are recorded as version snapshots in an audit table, automatically recording the previous version each time the twin instance table is updated; historical changes to dynamic parameters are naturally carried by the dynamic parameter time series table. Temporary errors such as database connection failures employ an exponential backoff retry strategy, with failed retry attempts written to a dead-letter queue for offline compensation. Based on data timestamps, historical activity data older than 3 years is automatically migrated to cold storage and the original table records are compressed; the migration process is transparent to upper-level queries.

[0119] Twin instances are generated based on the cleaned data stream. Each twin instance carries a globally unique twin ID and a corresponding metamodel version number, and is stored in the digital twin instance library. The twin instance encapsulates static and dynamic parameters. Static parameters are stored in the JSONB field and geometry column of the twin instance table, and dynamic parameters are stored in the dynamic parameter time series table. The twin instance automatically inherits the computational logic identifier associated with its metamodel to ensure that the corresponding computational rules can be accurately located during subsequent calculations.

[0120] Finally, S4 is executed, which performs spatial topology analysis based on the static parameters of each twin instance and the preset assembly rules to generate assembly edges. The composite twin is constructed from multiple twin instances and the assembly edges.

[0121] This step is implemented through a twin instance assembly module, which is responsible for dynamically combining discrete, independently stored twin instances into composite twins according to their spatial relationships in the real world to support subsequent applications. Assembly does not modify the original twin instances; it only stores logical associations through a spatial relationship table, supporting incremental updates and historical rollback.

[0122] The twin instance assembly module uses PostgreSQL and PostGIS 3.0+ as the spatial data storage and computation engine. The spatial index uniformly uses GIST, and pre-filtering of the bounding rectangle is performed using ST_DWithin combined with the maximum search radius. Spatial assembly employs a combination of rule-based spatial queries and graph traversal, and ST_Subdivide is enabled for the geometry field to optimize the query performance of very large polygon objects.

[0123] The preset assembly rules define multiple spatial relationship types and corresponding spatial predicates based on the static parameters of each twin instance. The spatial relationship types include at least: co-position assembly based on ST_Intersects, containment assembly based on ST_Covers, adjacency assembly based on ST_Touches, traversal assembly based on ST_Crosses, and distance constraint assembly based on ST_DWithin with a distance threshold configured, as shown in Table 6 below.

[0124] Table 6

[0125]

[0126] To simplify the assembly logic, assembly rules are configured based on common positional relationships of real-world physical entities. The spatial relationship constraints between various technical domain categories are as follows: when there is overlap between buildings, facilities, and the other three technical domains, the same relationship applies, and ST_Intersects(A, B) is used for determination; when there is overlap between green space or roads and other technical domain categories that contain themselves, the inclusion relationship applies, and ST_Covers(A, B) is used for determination; except for inclusion and same relationship, all category pairs can establish corresponding assembly relationships based on different spatial predicates as needed, and no prohibition rules are preset.

[0127] Assembly rules are managed independently in the rule table, supporting versioning and distance threshold configuration. The rule table includes fields such as: Technology Domain Category A, Technology Domain Category B, Relationship Type, Self-Loop Allowed, Priority, Distance Threshold, Version, and Usage Status. The Priority field is used for rule management and display sorting (larger values ​​appear earlier), but it does not participate in spatial relationship matching decisions. Spatial relationship matching strictly follows a preset type priority order: contains > crosses > touches > proximity > intersects. The distance threshold applies to adjacency and distance constraint relationships, and the distance threshold field for adjacency is used for tolerance in adjacency assembly. Versioning is achieved through a combination of the version and usage status fields; the usage status of the currently active version is TRUE. In the rule table, the directional conventions for technical domain category A and technical domain category B are as follows: In directed relationships, technical domain category A is the parent and technical domain category B is the child, applicable to containment and traversal constraints; undirected relationships are uniformly stored as technical domain category A < technical domain category B, applicable to sibling, adjacency, and distance constraints, except for self-loop relationships where technical domain category A and technical domain category B are equal. During queries, both orders are considered for undirected relationships.

[0128] The rule table has the following constraints: a distance threshold check constraint, ensuring that the distance threshold for distance constraints is not null; the distance threshold for adjacency relationships can be null, using the global default tolerance when null; and the distance threshold for other relationship types must be null. A version uniqueness constraint is uniquely determined by the combination of technology domain category A, technology domain category B, relationship type, and version. An active version uniqueness constraint ensures that only one active version exists under the same combination of technology domain category A, technology domain category B, and relationship type. To improve query efficiency, a partial index is created on the active status field (indexing only records where the active status is true), and a composite index is created on the technology domain category A, technology domain category B, and relationship type fields.

[0129] Before inserting a relationship, a validity check is performed via a trigger: This checks if the relationship type exists in the rule table with a currently active version, whether self-loops are allowed, and whether distance-based relationships have valid distance parameters for adjacency or distance constraints. When a new version of a rule is activated, the system provides an optional full or incremental relationship refresh mechanism to ensure data consistency. This can be triggered via a stored procedure or an external task, allowing for either clearing and rebuilding or incrementally updating only affected relationships based on actual business needs.

[0130] Spatial relationships are managed uniformly in the relational storage table. Specific directed / undirected direction conventions are defined in the assembly rule definition, and insertions also follow the direction conventions in the rule table. The relational storage table contains the following fields: assembly id (primary key, UUID type); twin A_id and twin B_id (associating twin instances respectively); relation type; and distance value (stores the actual distance of adjacency or distance constraints). The distance check constraints in this table are logically consistent with the rule table. Uniqueness constraints are determined by the combination of twin A_id, twin B_id, and relation type, as well as two foreign key constraints (cascading delete). To improve query efficiency, ordinary indexes are created on the twin A_id, twin B_id, and relation type fields.

[0131] The twin assembly process strictly follows a strategy of coarse screening followed by fine-tuning. Coarse screening uses ST_DWithin(A, B, maximum distance) to filter all potentially related twin pairs at once. The maximum distance is taken as the maximum distance threshold of adjacency and distance constraints among all rules; if no rule exists, the global default maximum search radius is used. Then, matching is performed according to the rules in the rule table. The system checks candidate twin pairs sequentially according to the preset priority order for each relation type to see if they satisfy the spatial predicate conditions of the corresponding relation type. Once a match is successful, subsequent judgments stop, and an assembly relation is established based on this relation type.

[0132] In the assembly determination, the twin with the larger geometric range is designated as the parent. In the adjacency assembly determination, minor gaps caused by data precision are covered by ST_DWithin during the coarse screening stage. During the fine-grained determination, it first checks if ST_Touches(A, B) is satisfied. If the rule table is configured with a tolerance distance, it further checks ST_DWithin(A, B, distance) AND NOT ST_Intersects(A, B) to ensure that they are adjacent but not overlapping within the given tolerance. The distance parameter is preferentially taken from the distance threshold field of the adjacent corresponding records in the rule table; if it is empty, the system's global default tolerance is used.

[0133] Because disjoint relations are numerous and lack practical semantics, they are not actively stored during the assembly process. Only in anomaly detection scenarios where "off-limits" relationships are explicitly recorded, `ST_Disjoint(A, B)` is used as a constraint, equivalently expressed by `NOT ST_Intersects(A, B)`, ensuring that spatial indexes are utilized. It should be noted that `ST_Disjoint` cannot utilize spatial indexes and is only suitable for small-scale anomaly detection, not for large-scale relation computation.

[0134] Furthermore, the assembly relationship of twin instances is maintained through a change capture and incremental update mechanism to ensure that spatial relationships are synchronized in real time as instances change. The system sets triggers on the twin instance table to monitor changes in geometric fields, technical domain categories, or metamodel IDs. The triggers write the change event (containing only the twin ID, operation type, summary information of the old and new categories, and the old and new geometric fields) to a local queue list, which is then asynchronously consumed by the independent message queue component Kafka. After the external listening service consumes this event, it initiates an independent transaction to perform incremental assembly: first, it calculates the scope of influence by taking the union of the old and new geometric buffers, with the buffer radius taken from all rules involving distance thresholds, i.e., the maximum distance defined in adjacency and distance constraints; then, it quickly queries candidate twins within this range using spatial indexes; next, it deletes relationships between the current instance and all instances in the candidate set that no longer satisfy any rules, while simultaneously traversing candidate pairs and sequentially calling spatial predicates according to the preset spatial relationship type priority order to determine whether they satisfy relationship types such as containment, crossing, adjacency, distance constraint, and co-location; relationships that satisfy these types and do not yet exist are inserted; finally, the transaction is committed. Change capture employs a persistent message queue, such as relying on PostgreSQL's pgmq extension or a standalone middleware, to implement peak shaving and retry mechanisms, ensuring reliability. Upon completion of the assembly task, an event is published to notify downstream modules. If an instance is deleted, all relation records involving that instance are directly removed, and the reassembly of its associated instances can be triggered optionally.

[0135] The system provides a full assembly mechanism for initialization or data repair. It clears the relationship table via stored procedures or external scripts and performs spatial relationship calculations on all twin instance pairs. Specifically, it utilizes the spatial index GIST to execute a ST_DWithin self-join query, combined with cursor batch processing and batch commits to prevent memory overflow.

[0136] Data consistency is ensured by a scheduled task. Daily comparisons satisfy the buffer radius condition, i.e., ST_DWithin(A, B, maximum distance), where the maximum distance is the instance pair with the maximum radius of the incremental assembly and existing relationship records are recorded, outputting candidate pairs that may have been missed. Simultaneously, it verifies whether each existing relationship still satisfies the corresponding spatial predicate; invalid relationships are marked for processing, and the results are written to an anomaly report table for manual review. Each change to the relationship table is recorded in the audit table via a trigger, storing the operation type, time, operator, and snapshots before and after the change to meet traceability requirements. Change capture is handled asynchronously, using a message queue to ensure at least one delivery and retries.

[0137] Based on the same inventive concept, this invention also proposes a method for obtaining carbon emissions and carbon sinks based on a composite twin. The composite twin is constructed based on the digital twin-based composite twin construction method described above, and includes the following steps:

[0138] In response to the accounting request, read the static and dynamic parameters of each twin instance in the composite twin;

[0139] Based on the computational logic identifier inherited by each twin instance, the corresponding version of the computational logic in the carbon emission and carbon sink computational model library is called;

[0140] The static and dynamic parameters are substituted into the calculation logic for processing to obtain carbon emission and carbon sink data for each twin instance.

[0141] The carbon emission and carbon sink acquisition method is the core embodiment of the value of the composite twin, and includes the following steps: First, responding to the accounting request, which can be triggered by a scheduled task or user operation, the request includes parameters such as the time range, spatial range, and twin ID. Then, reading the static and dynamic parameters of each twin instance in the composite twin, the dynamic parameters are read in batches from the independent time series table of dynamic parameters according to the time range, supporting high-concurrency queries. Next, based on the metamodel ID and metamodel version number recorded when the twin instance is created, locating the formula bound to the metamodel, parsing the variables and factor dependencies in the formula, and dynamically obtaining the corresponding factor values ​​through the factor library interface. Finally, substituting the dynamic parameters within the time range and the called factors into the expression engine (such as Aviator, MVEL) to perform calculations, obtaining the carbon emission and carbon sink data of the instance. This part will be explained in detail later.

[0142] Based on the same inventive concept, such as Figure 2 and Figure 3 As shown in the illustration, this invention also proposes a carbon emission and carbon sink monitoring system, which is divided into a data source layer, a data processing layer, a twin layer, a computing layer, an application layer, an API gateway layer, an interaction layer, and a public support system. The data processing layer collects and cleans the required data from the data source layer (such as IoT sensors, GIS platforms, government databases, and internet data); the twin layer includes a meta-model library, a twin instance generation module, and a twin assembly module for generating, assembling, and storing twins; the computing layer includes a carbon emission and carbon sink calculation model library and a carbon emission and carbon sink calculation module for converting activity data in the twins into carbon emission and carbon sink data; the application layer includes multi-dimensional data statistics and carbon emission monitoring and early warning, used to summarize and statistically analyze carbon emission and carbon sink results and perform dynamic monitoring and early warning; the interaction layer provides a 3D visualization dashboard, Web / mobile applications, etc.; the public support system includes a security and operation and maintenance system, a standards and specifications system, and a data and service bus, ensuring the system's security and normal operation.

[0143] Specifically, the data processing layer is configured to collect multi-source data, perform standardized cleaning, and encapsulate it into a data stream that conforms to the meta-model specification;

[0144] The twin layer includes a meta-model library, a twin instance generation module, and a twin assembly module; wherein...

[0145] The meta-model library is configured to be built based on a preset classification hierarchy. The classification hierarchy includes at least the top-level technology domain category and the bottom-level technology attribute type. Physical entities are abstracted into meta-models according to the technology attribute type. The meta-model is configured with a unified parameter interface.

[0146] The twin instance generation module is configured to verify the cleaned data based on the meta-model, and generate a twin instance carrying a unique twin ID and a corresponding meta-model version number based on the meta-model. The twin instance encapsulates static parameters and dynamic parameters, and inherits the computational logic identifier associated with its meta-model.

[0147] The twin assembly module is configured to perform spatial topology analysis based on the static parameters of each twin instance and preset assembly rules, generate assembly edges, and construct a composite twin from multiple twin instances and the assembly edges.

[0148] The computational layer includes a carbon emission and carbon sink calculation model library and a carbon emission and carbon sink calculation module. The carbon emission and carbon sink calculation model library includes independently stored formula and factor libraries; wherein,

[0149] The formula library is configured with predefined standardized interfaces to dynamically call factor values ​​from the factor library;

[0150] The carbon emission and carbon sink calculation module is configured to respond to a calculation request by calling the calculation logic in the formula library and the factor values ​​in the factor library to perform carbon emission and carbon sink calculation.

[0151] The carbon emission and carbon sink calculation model library is decoupled from the meta-models stored in the meta-model library.

[0152] In this embodiment, the carbon emission and carbon sink calculation module is the caller of the carbon emission and carbon sink calculation model library, responsible for quantitatively calculating carbon emission and carbon sink for the twin instance and storing the calculation results. The result visualization module supports multi-dimensional visualization of the calculation results.

[0153] The calculation triggering adopts a hybrid strategy of scheduled batch processing, real-time incremental processing, on-demand recalculation, and historical backfilling. Scheduled batch processing uses Airflow to schedule Spark jobs and calculates data for the corresponding time period according to the set time. Real-time incremental processing uses Flink to consume data in Kafka and send the calculation request to the task queue Kafka, which is processed uniformly by the calculation execution layer to avoid bypassing load balancing. On-demand recalculation is submitted via API and executed asynchronously in the background. It is manually triggered by the user in meta-model, twin instance, factor, formula change, or other business scenarios. Historical backfilling adopts Spark batch processing and incremental writing mode, and performs batch calculations according to the specified time range during system initialization or data repair.

[0154] The carbon emission and carbon sink calculation engine adopts a layered and decoupled architecture. The scheduling layer is responsible for receiving tasks, distributing them, and load balancing, using Kafka as the task queue. The accounting execution layer adopts a stateless worker cluster deployed on Kubernetes, where each worker consumes tasks and performs accounting. The model caching layer uses local Caffeine / Guava caching and remote Redis caching to store formula expressions and factor values ​​by (factor code, region, technology type, validity date) key, reducing database access. The storage layer uses PostgreSQL to store results and audit records, and time series data is read from the dynamic parameter time series table.

[0155] During the accounting process, this module receives an accounting request, including the twin ID, the start time of the accounting period, the end time of the accounting period, and the trigger type. Trigger types include batch, real-time, manual, and backfill. Based on the twin ID, the module queries the twin instance to obtain the metamodel ID, metamodel version, static parameters, and dynamic parameters within the accounting period's time window. Then, it calls the metamodel library to retrieve the list of applicable calculation processes for the twin from the applicable calculation process field of the metamodel. Each calculation process, based on the metamodel version recorded when the twin instance was created, retrieves the formula bound to that metamodel version from the carbon emission and carbon sink calculation model library, obtains the expression and factor references, parses the variables required by the formula, calls the factor library interface (factor code, region, technology type, validity date) to obtain the value of each dependent factor, and executes the formula using the expression engine Aviator / MVEL to obtain the result value of the process. The results of each calculation process are summarized as the total carbon emission / total carbon sink of the twin within that time window, written to the accounting result table, and simultaneously written to the calculation link audit table. Record the formula version, factor version, and input parameter snapshot used in this calculation, store them as JSONB, and record the evaluation process of each formula in a fine-grained manner to facilitate the traceability of historical results and debugging of anomalies. Finally, send a calculation completion event to the message queue.

[0156] The accounting results for the most recent three months are stored in a PostgreSQL accounting results table for fast querying. Historical data older than three months is migrated to a TimescaleDB compressed supertable or the columnar storage ClickHouse via a scheduled task. The application layer automatically routes queries based on time ranges through a unified data access service. Original accounting results are retained for five years to meet policy auditing requirements.

[0157] The visualization module for accounting results uses Node.js on the backend to provide a GeoJSON data interface, and MapboxGL JS and a heatmap plugin on the frontend. It employs a layered design: a vector topology base map displays twin instances such as 2D building outlines, road lines, and green space patches, and outputs the required data from the twin instance table using PostGIS's ST_AsGeoJSON. The dynamic heatmap displays the cumulative carbon emissions and carbon sinks of all twin instances within each spatial grid within a selected time range, differentiated by color. In small-scale scenarios, the backend queries the accounting results table in real time for each heatmap request, dynamically aggregating the results by Geohash according to the spatial grid. In large-scale scenarios, a pre-aggregation strategy is used to create an aggregation result table and pre-aggregate by spatial grid. Clicking on interactive layers allows querying the accounting results table and displaying static parameters and carbon emission / carbon sink value details of the twin instances through a popup window.

[0158] In this embodiment, the application layer includes multidimensional data statistics and monitoring and early warning based on the statistical results. The multidimensional data statistics application is deployed in the application layer of the digital twin platform, targeting scenarios such as urban planning, carbon accounting auditing, and industry supervision. It provides multidimensional summary statistics capabilities based on spatial location, meta-model classification hierarchy, and extended attributes, and supports any combination of dimensions for summary statistics, significantly improving the flexibility and usability of data statistics. The statistical data comes from the carbon emission and carbon sink accounting result table, and the static parameters and dimensional mapping information of the twin come from the digital twin instance library. The statistical results include: total carbon emissions (tCO2e), total carbon emissions (tCO2e), net emissions (tCO2e), carbon emission change rate (year-on-year and month-on-month), carbon sink change rate (year-on-year and month-on-month), net emissions change rate (year-on-year and month-on-month), and number of twins. Results are not counted when the data volume is insufficient for year-on-year and month-on-month calculations.

[0159] When conducting statistics based on geographic location information, instances are mapped to different spatial location granularities according to the geometric fields of twin instances. The corresponding grid code is calculated based on the geometric center of the twin instance. Statistics can be conducted by subdividing the study area into Geohash or H3 grids. The grid precision is specified by the user in the statistical request; the default precision for Geohash is 7, and for H3 it is 6. Spatial overlay analysis can be performed by calling PostGIS's ST_Covers, allowing statistics based on administrative boundary data (provincial, municipal, district / county, and township levels). Users can also upload custom geofences (GeoJSON format) for statistics. Administrative boundary data is imported from external GIS data or obtained through access from a third-party geographic information service platform. When conducting statistics based on the metamodel hierarchy, the hierarchical structure defined in the metamodel library (technology domain category → functional role category → technology attribute type) is used to group instances level by level through pre-defined hierarchical path fields, supporting roll-up and drill-down statistics along the classification hierarchy. When performing statistics based on industry information in extended attributes, the statistics are based on the industry information preset in the JSONB field of the extended attribute in the twin instance table. If the industry field names are inconsistent or the encoding format is not uniform in the original data, the data is standardized and converted through a configurable industry information mapping table.

[0160] Users can select any time period for statistical queries, with the time range supporting custom selection by start and end dates. Users can combine any dimension from geographic location information, metamodel hierarchy, and extended attributes, and dynamically construct GROUP BY clauses to sequentially add selected dimension fields to the grouping column, achieving multidimensional cross-statistics. For example, combining technology domain categories and administrative divisions can be used to analyze the composition of carbon emission and carbon sink results for various technology domains within a specific administrative region.

[0161] The system automatically generates cumulative statistical results at the monthly, quarterly, and annual levels based on key statistical dimensions preset by the administrator (such as "technology domain category + month", "administrative division + quarter", "industry category + year"). These preset key statistical dimensions are maintained by the administrator in the system configuration and can be added, deleted, or modified. The system automatically generates corresponding statistical results based on these preset dimensions, and users can directly select preset dimensions to view the corresponding cumulative data on the front end, without needing to manually configure dimension combinations each time. Preset calculation tasks are automatically triggered by the scheduling system, executing the cumulative calculations of the previous period according to a preset cycle (e.g., midnight on the 1st of each month) and persisting the results. Users can directly read the pre-calculated results when querying, without the need for real-time aggregation.

[0162] The carbon emission monitoring and early warning application continuously monitors key statistical dimensions (total carbon emissions, year-on-year / month-on-month carbon emission change rate, and net emissions) based on the key statistical dimensions preset by the multidimensional data statistical application and the automatically generated monthly, quarterly, and annual statistical results. It also issues early warning signals to users when preset early warning conditions are met.

[0163] Administrators can configure differentiated monitoring and alert rules for each key statistical dimension. Each rule includes: the monitoring dimension (which must be a key statistical dimension preset by the system), the monitoring indicator, the judgment logic (threshold comparison type or trend judgment type), and the alert text. Threshold comparison type rules support triggering alerts when the value is greater than, less than, equal to, or between a specified threshold. Trend judgment type rules support judgment methods such as increasing / decreasing for N consecutive months or the rate of change exceeding a threshold for N consecutive months.

[0164] The early warning engine works in conjunction with the statistical pre-calculation task. After each statistical pre-calculation result is persistently stored, the early warning engine automatically wakes up, reads all active early warning rules, compares the actual statistical values ​​with the rule judgment logic one by one, and generates an early warning record if the conditions are met. This record is then persistently stored and pushed in real time through a unified message interface, and the twin with the highest emission contribution in that dimension's aggregate range is highlighted on the visualization page. The highlighting is removed when the user closes the early warning record.

[0165] Based on the same inventive concept, embodiments of the present invention also propose a readable storage medium storing a computer program thereon, which, when executed, can realize the method for constructing a composite twin based on digital twins as described above.

[0166] A readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device, such as, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof. The computer programs described herein can be downloaded from the readable storage medium to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. Networks can include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. Each computing / processing device's network adapter card or network interface receives and forwards a computer program from the network for storage on a readable storage medium within the respective computing / processing device. The computer program used to perform the operations of this invention can be execution instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as "C" or similar languages. The computer program can execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), are personalized by utilizing state information from a computer program. These electronic circuits can execute computer-readable program instructions, thereby realizing various aspects of the present invention.

[0167] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, systems, and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by a computer program. These computer programs can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. These computer programs can also be stored in a readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the readable storage medium storing the computer program comprises an article of manufacture including instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams.

[0168] A computer program may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the computer program executing on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0169] In summary, this invention provides a method for constructing a composite digital twin, a method for acquiring carbon emissions and carbon sinks, a monitoring system, and a readable storage medium. Through a meta-model library, complex urban entities are abstracted into standardized models of a limited number of types with unified parameter interfaces. Its pre-defined geographic and activity data interfaces ensure that any entity accessing the system adheres to the same data specifications. This fundamentally solves the long-standing problems of data heterogeneity and system silos in the field of digital twins. Furthermore, model-based abstraction transforms the digital construction process of a city into an assembly logic. Through twin assembly, twins can be instantiated and combined based on real geographic information of any region, rapidly generating well-structured multi-scale models ranging from micro-industry levels to macro-city levels. Additionally, the activity data interface of the meta-model can be designed to consider the needs of carbon emission and carbon sink calculations in advance, making data streams directly related to carbon emissions and carbon sinks, such as energy consumption and production capacity, inherent attributes of the model, rather than post-hoc analytical items. This lays an unshakable foundation for end-to-end, traceable carbon management. In addition, through multidimensional data statistics, multidimensional analysis and monitoring and early warning of carbon emission and carbon sink data can be realized, flexibly adapting to diverse statistical needs such as higher-level planning, zoning management and industry supervision.

[0170] The above description is merely a description of preferred embodiments of the present invention and is not intended to limit the scope of the invention in any way. Any changes or modifications made by those skilled in the art based on the above disclosure are within the protection scope of the present invention. Obviously, those skilled in the art can make various modifications and variations to the present invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the present invention and its equivalents, the present invention also intends to include these modifications and variations.

Claims

1. A method for constructing a composite twin based on digital twins, characterized in that, include: A meta-model library is constructed based on a predefined classification hierarchy. This library reduces an infinite number of physical entities to a parameterized description system with a unified technical caliber and limited categories by defining finite types of technical attribute templates. The top level of the classification hierarchy is fixed as a technical domain category, representing the basic technical system type to which an entity belongs. The bottom level of the classification hierarchy consists of technical attribute types. The meta-model only performs instantiation at the bottom level of technical attribute types, which contains complete technical parameter descriptions. These descriptions include static and dynamic parameters that can be directly mapped to specific instances, serving as the smallest granular unit for data acquisition and model generation. The meta-model is configured with a unified parameter interface. Construct a carbon emission and carbon sink calculation model library independent of the meta-model library. The carbon emission and carbon sink calculation model library is associated with the meta-model library through a standardized interface to support independent iteration and version management of the calculation logic. Collect and clean multi-source data, verify the cleaned data based on the meta-model, and generate a twin instance carrying a unique twin ID and the corresponding meta-model version number based on the meta-model; the twin instance encapsulates static and dynamic parameters and inherits the computational logic identifier associated with its meta-model. Based on the static parameters of each twin instance and the preset assembly rules, spatial topology analysis is performed to generate assembly edges. The composite twin is constructed from multiple twin instances and the assembly edges. The preset assembly rules define various spatial relationship types and corresponding spatial predicates based on the static parameters of each twin instance. The spatial relationship types include at least: co-position assembly based on ST_Intersects, containment assembly based on ST_Covers, adjacency assembly based on ST_Touches, traversal assembly based on ST_Crosses, and distance constraint assembly based on ST_DWithin with a distance threshold configured. The steps for generating the twin instance include: Listen to the message queue to obtain the cleaned data, which includes the metamodel ID and version number; Call the parameter interface of the meta-model library to obtain the corresponding version of JSON Schema, verify the cleaned data, and transfer the data that fails the verification to the abnormal data pool; The verified data is matched against instances based on a unique business identifier or spatial location, wherein the unique business identifier has a higher priority than the spatial location. If a match is successful, the static parameters are merged and the time-series data of the dynamic parameters are appended; if a match fails, a new unique twin ID is generated to create an instance.

2. The method for constructing a composite twin based on digital twins according to claim 1, characterized in that, For the data that has passed the verification, the following are also included: The static parameters are written to the twin instance table in UPSERT mode, and the dynamic parameters are batch appended to the dynamic parameter time series table. The duplicates are removed by combining the unique twin ID of the twin instance with the timestamp. Among multiple data with the same timestamp, the last one is retained. The update of the static parameters and the writing of the dynamic parameters adopt an eventual consistency model. First, the twin instance table is updated, and then the dynamic parameters are appended to the dynamic parameter timing table. The version snapshot before the change corresponding to each update operation of the static parameters is recorded through an audit table. During the execution of the static parameter writing or the dynamic parameter writing operation, an exponential backoff retry strategy is adopted for temporary errors of database connection failure. After a retry fails, the error is written to a dead letter queue for offline compensation.

3. The method for constructing a composite twin based on digital twins according to claim 1, characterized in that, The spatial topology analysis employs a two-stage process combining coarse screening and fine judgment: First, based on the distance thresholds corresponding to all distance class rules, a coarse screening is performed using the ST_DWithin predicate to select candidate twin pairs; Subsequently, according to the preset spatial matching priority, the corresponding spatial predicates are called in sequence to perform fine-grained judgment on the candidate twin pairs. The spatial matching priority is: contain > traverse > adjacency assembly > distance constraint assembly > co-position assembly. Once a match is successful, the subsequent judgment is stopped and the assembly edge is established.

4. The method for constructing a composite twin based on digital twins according to claim 3, characterized in that, The assembly relationship of the twin instances is maintained through a change capture and incremental update mechanism, specifically including: Listen for changes to the geometry field, technology domain category, or metamodel ID of the twin instance using triggers; Take the union of the old and new geometric buffers as the scope of influence, and delete the old relations that have become invalid within the scope of influence; Traverse the candidate twin pairs within the influence range, re-determine the new relationship according to the spatial matching priority, and insert it; By using a timed task, the current spatial relationship of the geometry is compared with the existing relationship records, and failed relationships are marked and repaired.

5. The method for constructing a composite twin based on digital twins according to claim 1, characterized in that, The composite twin is a graph structure with the twin instance as nodes and the assembled edge as connecting edge; the edge features of the assembled edge include relation type encoding and distance value.

6. A method for obtaining carbon emissions and carbon sinks based on a composite twin, wherein the composite twin is constructed based on the composite twin construction method based on digital twins according to any one of claims 1-5, characterized in that, Includes the following steps: In response to the accounting request, read the static and dynamic parameters of each twin instance in the composite twin; Based on the computational logic identifier inherited by each twin instance, the corresponding version of the computational logic in the carbon emission and carbon sink computational model library is invoked; The static and dynamic parameters are substituted into the calculation logic for processing to obtain carbon emission and carbon sink data for each twin instance.

7. A carbon emission and carbon sink monitoring system, used to implement the method for constructing a composite twin based on digital twins as described in any one of claims 1-5, characterized in that, include: The data processing layer is configured to collect multi-source data, perform standardized cleaning, and encapsulate it into a data stream that conforms to the meta-model specification; The twin layer includes a meta-model library, a twin instance generation module, and a twin assembly module; among which, The meta-model library is configured to be built based on a preset classification hierarchy. The classification hierarchy includes at least the top-level technology domain category and the bottom-level technology attribute type. Physical entities are abstracted into meta-models according to the technology attribute type. The meta-model is configured with a unified parameter interface. The twin instance generation module is configured to verify the cleaned data based on the meta-model, and generate a twin instance carrying a unique twin ID and a corresponding meta-model version number based on the meta-model. The twin instance encapsulates static parameters and dynamic parameters, and inherits the computational logic identifier associated with its meta-model. The twin assembly module is configured to perform spatial topology analysis based on the static parameters of each twin instance and preset assembly rules, generate assembly edges, and construct a composite twin from multiple twin instances and the assembly edges. The computational layer includes a carbon emission and carbon sink calculation model library and a carbon emission and carbon sink calculation module. The carbon emission and carbon sink calculation model library includes independently stored formula and factor libraries; wherein, The formula library is configured with predefined standardized interfaces to dynamically call factor values ​​from the factor library; The carbon emission and carbon sink calculation module is configured to respond to a calculation request by calling the calculation logic in the formula library and the factor values ​​in the factor library to perform carbon emission and carbon sink calculation. The carbon emission and carbon sink calculation model library is decoupled from the meta-models stored in the meta-model library.

8. A readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed, it can implement the method for constructing a composite twin based on digital twins as described in any one of claims 1-5 and the method for obtaining carbon emissions and carbon sinks based on composite twins as described in claim 6.

Images