Green building carbon emission prediction method based on multi-source energy consumption data

Abstract

The application discloses a green building carbon emission prediction method based on multi-source energy consumption data, belongs to the technical field of green buildings, and aims to solve the problem that existing carbon emission prediction ignores demand adaptation, constraint integration and operation and maintenance instruction generation; the method comprises the following steps: collecting user demand signals and cross-domain data, constructing a demand-cross-domain data double library and a three-level subgraph and dynamically updating, predicting basic carbon emission, generating personalized verification results and pushing the user; constructing a device and policy constraint database, screening adaptive constraint data, forming a carbon emission-user demand-constraint information three-dimensional correlation system; generating device collaborative operation instructions, and calculating compliance parameters through a cost optimization function if the instructions violate rules, and issuing the instructions to a building equipment control system; the application can adapt to multi-role demand and cross-domain data in real time, reduce manual adjustment, clearly define constraints, improve operation and maintenance efficiency, avoid equipment linkage conflicts and policy violations, and help precise carbon emission reduction of green buildings.

Description

Technical Field

[0001] This invention belongs to the field of green building technology, specifically relating to a method for predicting carbon emissions from green buildings based on multi-source energy consumption data. Background Technology

[0002] Under the "dual carbon" goal, carbon emission reduction in green buildings has become a key focus. Although existing carbon emission predictions integrate multi-source data such as energy consumption and equipment to meet accuracy requirements, they focus on "accurate calculations" while neglecting dynamic adaptation to user needs, integration of equipment with policy constraints, and generation of operation and maintenance instructions. This results in predictions that are difficult to implement and low operation and maintenance efficiency. Based on this, the following technical issues are proposed:

[0003] The existing forecast outputs unified carbon emission data, which makes it difficult to capture real-time changes in demand such as homeowner renovations and tenant temperature adjustments. It also does not correlate with cross-domain data such as building material prices, resulting in low adaptability and the need for manual adjustments.

[0004] The prediction only outputs information on carbon emission exceeding the standard, without integrating equipment operating conditions, coupling logic, and policy compliance thresholds. Therefore, there is no constraint basis when generating equipment instructions, and it is impossible to judge the feasibility.

[0005] Without constraints, it is impossible to generate coordinated instructions for "target equipment - parameter adjustment - execution period". Manual verification of constraints delays emission reduction opportunities and is also prone to equipment conflicts or violations. To address this, we propose a green building carbon emission prediction method based on multi-source energy consumption data. Summary of the Invention

[0006] The purpose of this invention is to provide a method for predicting carbon emissions from green buildings based on multi-source energy consumption data, so as to solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a method for predicting carbon emissions from green buildings based on multi-source energy consumption data, comprising the following steps:

[0008] Step 1: Collect user demand signals and cross-domain data, build a dual database of demand and cross-domain data, and construct a three-level subgraph of fragment subgraph, semantic entity subgraph, and community subgraph based on it and update it dynamically; predict basic carbon emissions, match target demand signals, extract feature vectors and match them with Euclidean distance to obtain target community subgraph, verify effective correlation, generate valid final results and push them to users;

[0009] Step 2: Construct a set of constraint data types to form a database of equipment and policy constraints. Match related data with timestamps as the link, and filter requirement-adaptive constraint data by combining semantic entity subgraphs. Construct a relationship system with carbon emission data, user needs, and constraint information as three-dimensional data items.

[0010] Step 3: Sort the valid final results, break down and construct a set of core requirement keywords, and determine the appropriate requirement type; construct a set of equipment function description data, determine a set of candidate target equipment, analyze equipment operating parameters, screen core target equipment, and determine the instruction execution period; generate equipment collaborative operation instructions, and if there are violations, obtain compliance parameters and issue compliance instructions.

[0011] Preferably, in step one, the specific process of constructing the requirement-cross-domain dual database is as follows:

[0012] Real-time collection of demand signals from each user role;

[0013] For each collected demand signal, a corresponding collection timestamp is associated with it to form a key-value pair of demand signal content and collection timestamp;

[0014] Arrange all demand signal-timestamp key-value pairs in ascending order of timestamp to obtain a continuous demand time series;

[0015] Acquire cross-domain data from multiple fields and mark the corresponding update timestamps;

[0016] Store time-series streams and cross-domain data with timestamps separately;

[0017] Using timestamps as the association key, a mapping relationship is established between the demand database and the cross-domain database, forming a dual database of demand and cross-domain data.

[0018] Preferably, in step one, the specific process of constructing and dynamically updating the three-level subgraph of fragment subgraph - semantic entity subgraph - community subgraph is as follows:

[0019] Raw data is extracted from the demand-cross-domain data dual databases and stored in a structured manner according to data category, core content, timestamp, and source identifier to form fragment subgraphs;

[0020] Based on manually labeled samples, feature matching rules are constructed to identify user role entities, demand type entities, and data dimension entities in the fragment subgraph. Entity mapping relationships are constructed through frequency statistics and co-occurrence probability verification. Semantic entity subgraphs are formed with entities as nodes and mapping relationships as edges.

[0021] Extracting the mapping relationship between user role entities and demand type entities from the semantic entity subgraph is the core of clustering. After clustering, labels are added to the demand communities and stored to form a community subgraph.

[0022] Real-time monitoring of the core data update timestamps in the cross-domain database; once the preset update duration is reached, the old data is replaced, and the third-level subgraph is updated synchronously.

[0023] Preferably, in step one, the specific process of pushing the final verified result to the user is as follows:

[0024] Call the existing green building carbon emission prediction model, input the basic parameters of the period to be predicted, and output the basic carbon emission data of the period to be predicted;

[0025] Filter demand signals whose collection timestamp and the interval between the time period to be predicted are less than or equal to a preset time threshold, and establish a mapping table of the time period to be predicted and the target demand signal set.

[0026] Extract the core feature parameters corresponding to the target demand signal into a vector, calculate the Euclidean distance between it and the baseline vector of the community subgraph, and select the one with the smallest distance as the target community subgraph;

[0027] The system iterates through the target community subgraph to obtain valid target relationships; it then organizes the relationships into structured information according to user roles and preset templates, inputs it into a language model to generate preliminary results; after a reasonableness check, it obtains valid final results, integrates them, and pushes them to the corresponding users.

[0028] Preferably, in step two, the specific process for forming the equipment and policy constraint database is as follows:

[0029] Data on operating conditions, coupling logic, and policy constraints are obtained from building equipment management systems, equipment manufacturers' technical data, and regional housing and construction department compliance documents.

[0030] A set of constraint data types is constructed based on functional attributes. The core parameters of each type of constraint data are extracted through field identification, parameter parsing, and association integration.

[0031] The data is structured and stored according to constraint type, core parameters, collection timestamp, and data source to form a database of equipment and policy constraints.

[0032] Preferably, in step two, the specific process of filtering the requirement adaptation constraint data is as follows:

[0033] The timestamps for each carbon emission period in acquiring basic carbon emission data, the timestamps for collecting target demand signals, and the timestamps for collecting constraint data in the equipment and policy constraint database are all collected.

[0034] If the difference between any two timestamps is less than or equal to the corresponding preset threshold, then the corresponding data is determined to be a match;

[0035] Iterate through each carbon emission period timestamp in each carbon emission period timestamp, filter the constraint data in the constraint data collection timestamp that matches it, and establish a carbon emission period-constraint data mapping table;

[0036] For each target demand signal, the constraint data that matches it is selected from the constraint data collection timestamp and marked as time-matched constraint data. The core parameters of the data are extracted and associated with the constraint data identifier to form a set of time-matched constraint core parameters.

[0037] Preferably, in step two, the specific process of constructing the association system of carbon emission data, user requirements, and constraint information as three-dimensional data items is as follows:

[0038] Match the corresponding demand type entity from the target demand signal, extract all data dimension entities associated with the demand type entity, and form a set of demand-associated data dimension entities.

[0039] Compare the core parameters of the time matching constraints with the feature keywords of the set, retain the consistent constraint data as the demand adaptation constraint data, and organize them into a set; and construct a mapping table of demand type - target demand signal - demand adaptation constraint data set.

[0040] A mapping table of carbon emission periods associated with timestamps – constraint data mapping table of demand types – target demand signals – demand adaptation constraint data set mapping table;

[0041] Filter out the associated core timestamps where the difference between the three timestamps is ≤ a preset threshold; bind the corresponding carbon emissions, user needs, and constraint information to form an association system with the associated core timestamp as the index and three-dimensional data items.

[0042] Preferably, in step three, the specific process of decomposing the valid final results of the sorted output into a set of core requirement keywords and determining the appropriate requirement type is as follows:

[0043] Extract all valid final results, arrange them in ascending order according to the timestamps of the target demand signals they are associated with, and then perform the decomposition one by one;

[0044] For each result, segment the words to obtain an initial vocabulary set, compare the words with the preset requirement keyword library, combine the word frequency, calculate the requirement relevance, and retain qualified words to construct a core requirement keyword set;

[0045] Extract the demand type entities and their exclusive keyword sets from the semantic entity subgraph, calculate the semantic overlap between the core demand keyword set and the keyword sets of each demand type entity, and select the demand type entity with the highest overlap as the adapted demand type.

[0046] Preferably, in step three, the specific process of generating device collaborative operation instructions is as follows:

[0047] Integrate the unique identifiers and functional descriptions of each device to form a set of device functional description data;

[0048] For each device, the association weight formula is used to calculate the association weight of each device, and devices that meet the association weight criteria are selected to form a set of candidate target devices;

[0049] Substitute the corresponding adaptation requirement type of the effective final result into the three-dimensional association system and match the corresponding constraint information;

[0050] Process the set of core requirement keywords to obtain the set of requirement values, and compare the constraint information to output the set of device operating parameters - values / value ranges;

[0051] Calculate the matching degree of candidate equipment requirements, and select the preset number of equipment with the highest matching degree as the core target equipment;

[0052] Extract high-carbon periods and screen policy effective periods, and take the intersection of the two as the instruction execution period;

[0053] Integrate core target equipment, operating parameters, and execution time periods, and generate equipment collaborative operation instructions according to the logic of target equipment - parameter adjustment - execution time period;

[0054] Generate device collaborative operation instructions based on the logical association of target device, parameter adjustment, and execution time period.

[0055] Preferably, in step three, the specific process of obtaining compliance parameters and issuing compliance instructions upon violation is as follows:

[0056] Call the equipment and policy constraint database constructed in the previous steps of constraint data processing and three-dimensional association system construction, and extract the constraint parameter thresholds corresponding to the core target equipment and the type of adaptation requirements;

[0057] Set the conditions for determining whether an instruction violates the rules;

[0058] If the equipment collaborative operation command is determined to be an illegal command, construct a cost optimization function:

[0059] F(P) = α·C(P) + β·Cost(P);

[0060] Wherein, F(P) represents the total operating cost of the core target equipment;

[0061] α and β are preset weighting coefficients;

[0062] C(P) represents the carbon emissions corresponding to parameter P;

[0063] Cost(P) is the operating cost corresponding to parameter P;

[0064] Using the constraint parameter threshold as the boundary condition, the minimum value of F(P) is obtained by gradient descent to find the parameter adjustment parameter corresponding to the compliance.

[0065] The adjustment parameters of the equipment collaborative operation instructions are replaced with compliant adjustment parameters to form compliant equipment collaborative operation instructions, which are then sent to the building equipment control system of green buildings. The system drives the core target equipment to execute the instructions.

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

[0067] (1) The green building carbon emission prediction method based on multi-source energy consumption data constructs a time-series stream by collecting demand signals from multiple roles such as owners and tenants in real time, and connects with third parties to obtain cross-domain data such as building material prices and electricity prices to build a dual database; through dynamic updating of the three-level subgraph and matching the target community subgraph with Euclidean distance, personalized verification results are generated according to roles, improving demand adaptability and reducing manual adjustments.

[0068] (2) The green building carbon emission prediction method based on multi-source energy consumption data constructs a database by obtaining operating conditions, coupling logic and policy constraint data from multiple sources, and uses timestamps for initial screening and semantic entity subgraphs for fine screening to adapt constraint data; establishes a three-dimensional system of carbon emission-demand-constraint to achieve accurate data correlation, provide clear constraints for subsequent instruction generation, and avoid unfounded judgments.

[0069] (3) The green building carbon emission prediction method based on multi-source energy consumption data generates a “target equipment - parameter adjustment - execution period” collaborative instruction. If there is a violation, the cost optimization function is used to find the compliance parameters, taking into account both emission reduction and cost. The compliance instruction is sent to the control system to avoid equipment linkage conflicts and policy violations, and improve the operation and maintenance efficiency during high carbon periods. Attached Figure Description

[0070] Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0071] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0072] Example 1;

[0073] Please see Figure 1 This invention provides a method for predicting carbon emissions from green buildings based on multi-source energy consumption data, including:

[0074] Step 1: Collect user demand signals and cross-domain data to build a dual database of demand and cross-domain data. Based on this, construct a three-level subgraph system: fragment subgraph, semantic entity subgraph, and community subgraph, and update it dynamically. Predict basic carbon emissions, match target demand signals, extract feature vectors, and match them using Euclidean distance to obtain the target community subgraph. Verify valid associations, generate a valid final result, and push it to users. The specific process is as follows:

[0075] Through the user interaction terminal of green building, demand signals from various user roles are collected in real time. Demand signals include: the identification of the new building to renovation stage submitted by the owner, and the adjustment instructions of summer comfort threshold (such as adjusting from 24℃ to 25℃) fed back by the tenant, and other quantifiable or identifiable demand information.

[0076] For each collected demand signal, a corresponding collection timestamp is associated to form a key-value pair of demand signal content and collection timestamp; the purpose is to ensure that each demand can be traced back to a specific time point.

[0077] Sort all demand signal-timestamp key-value pairs in ascending order of timestamp, remove duplicate and invalid signals (such as empty feedback and format error signals), and obtain a continuous demand time sequence stream;

[0078] By connecting to third-party emission reduction-related data nodes through the external data access port of green building, we can synchronously obtain cross-domain data from multiple fields and mark the corresponding update timestamp for each type of cross-domain data.

[0079] Among them, the third-party emission reduction related data nodes include: building materials e-commerce platforms, power grid marketing management systems, regional housing and construction department compliance platforms, and other third-party emission reduction related data nodes.

[0080] Cross-domain data includes: real-time price fluctuation data of building materials such as steel and photovoltaic panels output by building materials e-commerce platforms; regional time-of-use electricity price peak and valley periods (such as peak electricity price from 8:00 am to 10:00 pm) adjustment data pushed by the power grid marketing system; and updated data on green building carbon emission compliance standards released by the housing and construction department.

[0081] Pre-set a requirements database and a cross-domain database. Store the time-series requirements in the requirements database, and store the timestamped cross-domain data in the cross-domain database.

[0082] By using a data association engine and timestamps as association keys, a mapping relationship is established between the demand database and the cross-domain database, forming a dual database of demand and cross-domain data. The purpose is to align the time dimension of demand and cross-domain data.

[0083] Based on requirements—a cross-domain dual-database structure—a three-level subgraph is constructed: fragment subgraph, semantic entity subgraph, and community subgraph. Specifically:

[0084] Raw data is extracted from the demand and cross-domain data dual databases. The raw data includes: demand signal content, collection timestamp, and user role information in the demand database; and cross-domain data content, update timestamp, and data source information in the cross-domain database.

[0085] The raw data is structured and stored according to the format of data category - core content - timestamp - source identifier, forming fragment subgraphs;

[0086] The data categories include: demand-related data and cross-domain data;

[0087] The core content includes: demand signal content for demand-related data and cross-domain data content for cross-domain data;

[0088] Timestamps: timestamps for collecting requirement-related data and timestamps for updating cross-domain data;

[0089] Source identifiers: user roles for demand-related data, and data sources for cross-domain data (such as building materials e-commerce / power grid systems).

[0090] Based on manually labeled samples, feature matching rules are constructed to identify user role entities, demand type entities, and data dimension entities in the fragment subgraph.

[0091] The corresponding mapping relationship between entities is constructed by frequency statistics and co-occurrence probability verification.

[0092] Using entities as nodes and the mapping relationships between entities as edges, a semantic entity subgraph is formed by organizing the graph structure. The semantic entity subgraph is presented as a logical association of user role → requirement type → data dimension.

[0093] Furthermore, the specific process of identifying user role entities, demand type entities, and data dimension entities in the fragment subgraph, and constructing the mapping relationships between each pair of entities, is as follows:

[0094] Entity recognition:

[0095] Three core entity types were identified: user role entities (such as "owner" and "tenant"), demand type entities (such as "renovation demand" and "comfort demand"), and data dimension entities (such as "building material price" and "electricity price").

[0096] Select raw data of a preset proportion from the fragment subgraphs and manually label the core entities corresponding to each type of data (e.g., adjust the labeling of the summer comfort threshold reported by tenants to: User Role: Tenant, Requirement Type: Comfort Requirement).

[0097] Based on labeled samples, entity feature matching rules are manually established (e.g., demand signals containing the keyword "renovation" correspond to the entity "renovation demand", and cross-domain data containing the keyword "price" correspond to the entity "building material price / electricity price").

[0098] The entity feature matching rules are applied to all the original data of the fragment subgraph to automatically extract three types of core entities and form an entity set.

[0099] Mining mapping relationships between entities:

[0100] The extracted entity set is organized according to the combination format of user role-demand type-data dimension, and the frequency of occurrence of each combination is counted (e.g., the frequency of occurrence of the tenant-comfort demand-electricity price combination).

[0101] A preset frequency threshold is used to filter out combinations of user roles, demand types, and data dimensions that are greater than or equal to the corresponding preset threshold, forming frequent itemsets;

[0102] Calculate the co-occurrence probability among entities in the frequent itemset (e.g., the co-occurrence probability of tenants and comfort requirements, and the co-occurrence probability of comfort requirements and electricity prices), and retain the association relationships with co-occurrence probabilities ≥ preset thresholds;

[0103] The filtered entity-relationship structure is stored in a graph structure (entities are nodes, and relationships are edges), forming a semantic entity subgraph.

[0104] Based on the constructed semantic entity subgraph, the mapping relationship between user role entities and demand type entities in the subgraph is extracted as the core object of clustering, and a clustering algorithm is used to cluster the scenarios. When clustering, the user role consistency and demand type similarity are used as the criteria, and the mapping relationship between user role entities and demand type entities and related data that meet the conditions are grouped into the same demand community.

[0105] Each community with a specific need is given a unique tag, and the tags are stored in the format of community tag - associated dataset to form a community subgraph;

[0106] The logic for constructing the associated dataset is as follows: taking the user role entity and demand type entity obtained by clustering as the core, synchronously associate their corresponding data dimension entities and the complete mapping relationship between the three from the semantic entity subgraph (such as tenant → comfort demand → electricity price), to ensure that the dataset contains full-link information of role-demand-data.

[0107] The community subgraph is presented as follows: with the community tag as the top-level core node, the user role entity, demand type entity, and data dimension entity in the associated dataset as the bottom-level nodes, and the mapping relationship between entities as the connecting edges, thus constructing a hierarchical graph structure.

[0108] The specific process of further using clustering algorithms to cluster scenes is as follows:

[0109] The core clustering indicators are user role consistency (e.g., whether they are all "tenants" or "owners") and "demand type similarity" (e.g., judging whether "comfort adjustment" and "seasonal temperature demand" are similar by keyword matching or feature distance).

[0110] From the mapping relationship of the semantic entity subgraph, extract the associated data containing user role entities and demand type entities as clustering objects;

[0111] Following the logic of first matching user roles and then determining the similarity of demand types, related data with the same user role and similar demand types are grouped together to form a preliminary demand community.

[0112] Verify the consistency of data across groups, remove outlier data that does not match the same roles and similar needs, and finally determine the demand community groups.

[0113] Real-time monitoring of update timestamps for core data in cross-domain databases, and preset corresponding update durations for each type of core data;

[0114] If the interval between the current time and the core data update timestamp reaches its preset update duration, the latest data will be automatically retrieved and the old data in the cross-domain database will be replaced.

[0115] Based on the updated core data, the third-level subgraph is updated synchronously, namely: locating the nodes corresponding to the old data in the fragment subgraph, the entity-relationship edges associated with the old data in the semantic entity subgraph, and the associated datasets related to the old data in the community subgraph. After removing invalid information, the third-level subgraph construction logic is used to write the nodes, relationship edges, and datasets corresponding to the new data into the corresponding subgraph to ensure that the third-level subgraph is consistent with the cross-domain database data.

[0116] Call the existing green building carbon emission prediction model, input the basic parameters of the period to be predicted, and output the basic carbon emission data of the period to be predicted;

[0117] The basic parameters include: total building area, power of main equipment, historical energy consumption data for the past three months, and meteorological data for the period to be predicted.

[0118] The basic carbon emission data for the forecast period includes: hourly carbon emission values ​​within the forecast period, total carbon emissions for the period, and the distribution of high carbon emission periods.

[0119] Extract the acquisition timestamps of each demand signal in the demand time series, filter out the demand signals whose acquisition timestamps are less than or equal to the time interval to be predicted by a preset time threshold, and construct a target demand signal set. Based on this, establish a mapping table between the time interval to be predicted and the target demand signal set.

[0120] For each target demand signal, core feature parameters are extracted from the basic carbon emission data of the corresponding prediction period, specifically including: the total carbon emission value of the prediction period, the start / end time of the high carbon emission period, and the peak carbon emission of the high carbon emission period.

[0121] The core feature parameters are organized into core feature vectors, and corresponding feature reference vectors are preset for each community subgraph. Based on the Euclidean distance algorithm, the Euclidean distance between the core feature vector and the reference vector of each community subgraph is calculated. The community subgraph with the smallest distance is selected and marked as the target community subgraph.

[0122] The search starts with the user role-demand type in the target community subgraph and limits the search scope to the data dimension entities associated with the starting node in the semantic entity subgraph (such as electricity price associated with comfort demand).

[0123] Traverse layer by layer from the starting node: first traverse the first-level nodes (e.g., comfort needs → electricity price), then traverse the second-level nodes (e.g., electricity price → summer peak and off-peak periods), and simultaneously organize the complete combination of user roles, demand types, and data dimensions formed during the traversal process;

[0124] Verify the user role-requirement type-data dimension combination obtained by traversal. If the data dimension entity in the combination (such as summer electricity price peak and valley) has valid data for the corresponding time period (such as July summer electricity price data) in the cross-domain database, it is determined to be a match. The successfully matched target association is retained and marked as a valid target association.

[0125] Pre-defined output templates are provided for different user roles;

[0126] For example, the owner-side template includes modules such as: emission reduction targets for the forecast period, renovation plan suggestions, building material price calculation, and investment return cycle;

[0127] The tenant-side template includes modules such as: temperature adjustment suggestions for the forecast period, carbon emission reduction corresponding to temperature adjustment, electricity cost changes corresponding to temperature adjustment, and comfort guarantee threshold.

[0128] The user roles, demand types, cross-domain data, and basic carbon emission data for the period to be predicted in the effective target association relationship are organized into structured input information according to template modules;

[0129] For example, the tenant's input information is: User role: Tenant, Request type: Comfort adjustment, Cross-domain data: July peak-valley electricity price (0.8 yuan / kWh from 8:00 to 22:00), Basic carbon emissions: High carbon period 8:00 to 10:00;

[0130] Structured input information is fed into an existing language generation model, and preliminary personalized results are generated based on a preset output template.

[0131] By using preset rationality verification rules (e.g., tenant temperature adjustment suggestions must ensure a comfort threshold of 24-26℃; owner investment return period must be ≤5 years), the preliminary results corresponding to the effective target correlation are verified, content that does not conform to the rules is eliminated, and the preliminary results that conform to the rules are retained and marked as valid final results;

[0132] All valid final results corresponding to the same target demand signal are integrated and pushed to the user corresponding to that target demand signal.

[0133] It should be noted that by collecting quantifiable demand signals from different roles such as owners (e.g., new building to renovation identification) and tenants (e.g., summer comfort threshold adjustments) through green building user interaction terminals, and linking these signals with collection timestamps to form a time-series stream, the drawbacks of existing technologies that "uniformly output carbon emission values / curves" are effectively avoided. This enables real-time perception of changes in user demand. At the same time, duplicate and invalid signals are eliminated to ensure the accuracy of demand data, laying the foundation for subsequent adaptation to cross-domain data and generation of personalized results. This significantly improves the adaptability of output information to users' real-time needs and reduces manual adjustment costs and interpretation biases.

[0134] By connecting to third-party nodes such as building materials e-commerce platforms, power grids, and housing and construction departments through external data access ports, cross-domain data such as building material prices, time-of-use electricity prices, and compliance standards are obtained and updated with timestamps. Then, using these timestamps as the association key, a dual database of demand and cross-domain data is constructed, aligning the time dimension of demand with that of cross-domain data. This design solves the problem of existing technologies "ignoring cross-domain data association," allowing carbon emission prediction to no longer rely solely on energy consumption data, but rather integrate multi-dimensional information such as economic data (e.g., electricity prices) and policy data (e.g., compliance standards), providing comprehensive data support for subsequent subgraph construction and association verification.

[0135] The fragment subgraph stores raw data in a structured manner according to "data category - core content - timestamp - source identifier". The semantic entity subgraph identifies roles, needs, and data dimension entities through feature matching rules and establishes mapping relationships. The community subgraph is clustered according to "consistent roles + similar needs" scenarios, forming a hierarchical data organization system. This allows scattered needs and cross-domain data to form a clear "role-need-data" link. At the same time, cross-domain data updates are monitored in real time. After a preset time, old data is automatically replaced and the subgraph is updated synchronously to ensure the timeliness of data and subgraphs. This avoids prediction deviations caused by data lag and provides a high-quality data carrier for subsequent accurate matching of target community subgraphs and verification of correlations.

[0136] After calling the carbon emission prediction model to output basic data, the Euclidean distance algorithm is used to match the target community subgraph that best matches the target demand signal. Then, the subgraph is traversed to verify the cross-domain data validity of the "role-demand-data" combination, ensuring that the correlation is real and usable. Subsequently, personalized templates are preset according to user roles (owner side includes renovation plan and return on investment, tenant side includes temperature adjustment suggestions and electricity cost changes), combined with rationality verification (such as tenant comfort threshold of 24-26℃) to generate valid final results. This solves the problem of existing technology "prediction results only output excessive values ​​and are difficult to implement", so that the results directly match the actual needs of users, without the need for secondary manual interpretation, improving operation and maintenance efficiency. At the same time, it provides accurate demand and data basis for step two to build a three-dimensional correlation system and step three to generate equipment instructions.

[0137] Step Two: Construct a set of constraint data types to form a database of equipment and policy constraints. Match related data using timestamps as a link, and filter requirement-adaptive constraint data using semantic entity subgraphs. The specific process of constructing a three-dimensional data item association system based on carbon emission data, user requirements, and constraint information is as follows:

[0138] Based on a multi-source data targeted connection method, constraint data is obtained from building equipment management systems, equipment manufacturers' technical data, and regional housing and construction department compliance documents;

[0139] Constraint data includes: operating condition constraint data, coupling logic constraint data, and policy constraint data;

[0140] Operating condition constraint data: unique equipment identifier, real-time load rate, operating status (power on / power off / fault), real-time output parameters (temperature / airflow / power) and data acquisition time;

[0141] Coupled logic constraint data: associated device groups (a set of multiple devices with linkage / mutual exclusion relationships), device parameter association rules, and device operation mutual exclusion conditions;

[0142] Policy constraint data: compliance indicators for carbon emissions of green buildings, threshold ranges for indicators, effective periods and issuing entities;

[0143] Based on the functional attributes of constraint data, a set of constraint data types is constructed, including: working condition constraint type, coupled logic constraint type, and policy constraint type.

[0144] For each type of constraint data, core parameters are extracted using a unified method of field identification, parameter parsing, and association integration. The specific process is as follows:

[0145] Field identification: Traverse the constraint data text to locate three key fields: core object identifier, quantifiable indicators, and associated time / subject.

[0146] Operating condition constraints: The core object identifier is the unique identifier of the equipment in the equipment function description data set, the quantifiable index is the equipment operating condition quantification field, and the associated time / subject is the operating condition collection timestamp;

[0147] Coupling logic constraints: The core object identifier is the associated equipment group identifier preset by the building equipment management system, the quantifiable indicator is the equipment association rule logic field, and the association time / subject is the coupling logic effective condition field;

[0148] Policy constraints: The core object is identified by the name of the compliance indicator in the compliance documents of the regional housing and construction department, the quantifiable indicator is the compliance standard threshold field, and the associated time / subject is the policy effective period and the issuing entity field;

[0149] Parameter parsing: Extracting information about the matching constraint type functional attributes from three types of key fields:

[0150] Operating condition constraints: Analyze the equipment operating condition parameters (load rate, output parameter values / ranges) in quantifiable indicators and the associated time / acquisition time in the main body to extract operating status feature identifiers;

[0151] Coupled logic constraints: Parse the logical relationships (greater than / less than / equal to) and thresholds of device association rules in quantifiable indicators, and extract the effective conditions in the association time / subject;

[0152] Policy constraints: Analyze the threshold range of compliance indicators in quantifiable metrics, and extract the policy effective period and issuing entity from the associated time / subject.

[0153] Related integration:

[0154] The core object identifier, quantifiable parameters / feature identifier, and associated time / subject parsing results are logically and structurally bound according to constraint object → constraint standard → constraint effective condition to form the core parameters of each type of constraint data;

[0155] The constraint data for each type is structured according to constraint type, core parameters, data collection timestamp, and data source, where:

[0156] Constraint types include three categories: operating conditions, coupled logic, and policy constraints;

[0157] Core parameters include: the core parameters of various constraint data;

[0158] The data acquisition timestamp is the time the data was acquired.

[0159] Data sources include: building equipment management systems, equipment manufacturers' technical data, and regional housing and construction departments;

[0160] All structured constraint data is organized and stored to form a database of equipment and policy constraints;

[0161] The timestamps of carbon emission records for each time period in the basic carbon emission data, the timestamps of the collection of each demand signal in the demand time series, and the timestamps of the collection of each constraint data in the equipment and policy constraint database are obtained and constructed into a corresponding timestamp set.

[0162] The timestamps for each carbon emission period in acquiring basic carbon emission data, the timestamps for collecting target demand signals, and the timestamps for collecting constraint data in the equipment and policy constraint database are all collected.

[0163] A preset time matching threshold is set. If the difference between any two timestamps is less than or equal to the corresponding preset threshold, the corresponding data is determined to be a match.

[0164] Iterate through each carbon emission period timestamp in each carbon emission period timestamp, filter the constraint data in the constraint data collection timestamp that matches it, and establish a carbon emission period-constraint data mapping table;

[0165] For each target demand signal, select constraint data that matches the demand signal acquisition timestamp from the constraint data acquisition timestamp and mark it as time-matched constraint data;

[0166] Extract core parameters from each time-matching constraint data and associate them with the corresponding constraint data identifier to form a set of time-matching constraint core parameters;

[0167] Based on the semantic entity subgraph constructed in step one, the corresponding demand type entity is matched from the target demand signal, and then all data dimension entities associated with the demand type entity are extracted to form a demand-associated data dimension entity set.

[0168] For each core parameter in the set of core parameters for time matching constraints, based on the preset data dimension entity feature matching rules (extracted from manually annotated samples of fragment subgraphs, such as "parameters containing the keyword 'temperature' correspond to the entity 'equipment temperature'"), the feature keywords of the core parameter are parsed and compared with the feature keywords of each entity in the set of entities in the data dimension associated with the requirements:

[0169] If the core parameter feature keyword is consistent with the entity feature keyword of a certain data dimension, then it is determined that the constraint data to which the core parameter belongs is consistent with the data dimension associated with the requirement type, the constraint data is retained, and recorded as requirement adaptation constraint data;

[0170] If the core parameter feature keywords are inconsistent with the entity feature keywords of all data dimensions, then the constraint data to which the core parameter belongs is determined to be unrelated to the data dimension associated with the requirement type, and the constraint data is removed.

[0171] All demand adaptation constraint data of the same target demand signal are organized by constraint data identifier - core parameter - acquisition timestamp to obtain the demand adaptation constraint data set of the target demand signal;

[0172] Collect all target demand signals' demand adaptation constraint data sets, and construct a mapping table of demand type - target demand signal - demand adaptation constraint data set based on the demand type corresponding to each target demand signal;

[0173] Using timestamps as a link, the carbon emission period - constraint data mapping table is associated with the demand type - target demand signal - demand adaptation constraint data set mapping table: the core timestamps of association are selected when the difference between the carbon emission period timestamp, the target demand signal acquisition timestamp, and the demand adaptation constraint data acquisition timestamp is ≤ a preset time matching threshold.

[0174] Bind corresponding carbon emission data, user demand data, and constraint information; form an association system with the core timestamp as the index and carbon emission data, user demand, and constraint information as three-dimensional data items.

[0175] It should be noted that by acquiring constraint data such as operating conditions (equipment load, operating status), coupling logic (equipment linkage / mutual exclusion rules), and policies (carbon emission compliance thresholds) from multiple sources, extracting core parameters through a unified process, and building a database, a comprehensive basis is provided for judging the feasibility of subsequent equipment instructions, solving the inefficiency problem of existing technologies lacking clear constraints and requiring manual verification.

[0176] First, the data is initially screened for matching based on timestamps. Then, combined with the semantic entity subgraph from step one, the constraint parameter keywords are compared according to the data dimensions associated with the requirements. Only the matching data is retained, avoiding interference from irrelevant constraints, which greatly improves the matching degree between constraint data and user needs.

[0177] By linking carbon emission data, user needs, and constraint information with core timestamps, a three-dimensional association system is constructed to break down the data silos among the three, ensuring that each type of data is accurately associated in time and logic, and providing a clear data link for generating compliant equipment collaborative instructions in step three.

[0178] Step 3: Sort the valid final results, break down and construct a core requirement keyword set, determine the appropriate requirement type; construct a device function description data set, determine the candidate target device set, analyze device operating parameters, screen core target devices, determine the instruction execution time period, and generate device collaborative operation instructions; for violations, obtain compliance parameters and issue compliance instructions. The specific process is as follows:

[0179] Extract all valid final results from step one. Using the target demand signal acquisition timestamp associated with each valid final result as a reference, arrange all valid final results in order of acquisition time from earliest to latest to obtain an ordered sequence of valid final results.

[0180] Based on the valid final result sequence, each valid final result is sequentially subjected to adaptation requirement type-device-parameter decomposition;

[0181] The specific decomposition process for each valid final result in the ordered set is as follows:

[0182] The valid final result text is segmented to obtain an initial vocabulary set;

[0183] A pre-defined keyword library for green building needs is provided, which contains all common keywords related to green building needs, such as temperature regulation, emission reduction, and energy conservation.

[0184] For each word in the initial vocabulary set, count the number of times the word appears in the initial vocabulary set to obtain the word frequency value;

[0185] Compare the vocabulary with the vocabulary in the preset keyword library one by one;

[0186] If the word matches any word in the keyword library, then the word is determined to match the required keyword library, and the matching score is set to 1.

[0187] If the word does not match any of the words in the keyword database, it is considered a mismatch and the matching score is set to 0.

[0188] The demand relevance can be obtained using the formula: Demand relevance = (Frequency of occurrence of words / Total number of words in the initial vocabulary set) × Matching score;

[0189] Preset a threshold for demand relevance, retain words with demand relevance greater than or equal to the preset threshold, and organize them into a set of core demand keywords corresponding to the effective final result;

[0190] Extract all demand type entities from the semantic entity subgraph and construct a unique keyword set for each demand type entity;

[0191] Furthermore, the specific process of constructing a unique keyword set for each demand type entity is as follows:

[0192] Extract demand signal text samples associated with demand type entities from the fragment subgraph;

[0193] The sample text is segmented into words, and words directly related to the type of need are manually labeled (e.g., words such as temperature, airflow, and body feeling are labeled in the comfort need sample).

[0194] The manually annotated words are compared one by one with the entity feature matching rules preset in step one:

[0195] If the labeled words contain any of the feature keywords corresponding to the entity of this demand type, then the labeled words are retained;

[0196] If the labeled words do not contain any characteristic keywords corresponding to the entity of this demand type, they are judged as irrelevant labeled words and removed.

[0197] The selected and retained labeled words are compiled into a set of exclusive keywords for entities of this demand type.

[0198] For each set of entity keywords for each demand type, count the number of intersections between the core demand keyword set and the demand type entity keyword set, and record this as the word intersection.

[0199] The number of the unions between the core demand keyword set and the demand type entity keyword set is counted and denoted as the word union.

[0200] Using the formula: Semantic overlap = Lexical intersection / Lexical union, we can obtain the semantic overlap between the core requirement keyword set and the entity keyword set of each requirement type.

[0201] The entity of the requirement type with the highest semantic overlap is selected as the appropriate requirement type for the valid final result.

[0202] Furthermore, a consistency check is performed between the adapted requirement type and the initial associated requirement type in the valid final result (derived from step one: the initial association of target community subgraph - user role - requirement type).

[0203] If the two are consistent, the requirement type determination of the valid final result is confirmed to be valid, the current requirement type label is retained, and the semantic overlap value is simultaneously added to the requirement type verification field of the valid final result to provide a verification basis for subsequent data traceability.

[0204] If the two are inconsistent, the data that matches the requirement type will be used to update the following related data:

[0205] Modify the requirement type field of the valid final result and replace the original preceding associated requirement type;

[0206] Synchronously update the relationship between the demand type entity and the data dimension entity corresponding to the valid final result in the semantic entity subgraph (e.g., the original relationship: comfort demand → electricity price, is corrected to: "energy saving demand → electricity price").

[0207] Adjust the requirements – the cross-domain data matching label corresponding to the valid final result in the cross-domain data dual database (e.g., the original matching “comfort-related electricity price data” is adjusted to “energy-saving related electricity price data”) to ensure that subsequent constraint parameter matching, equipment association and other processes are carried out based on the accurate requirement type.

[0208] Based on the equipment operation and maintenance manuals and equipment manufacturers’ technical data in green buildings, the unique identifiers and functional descriptions of each piece of equipment are integrated to form a set of equipment functional description data.

[0209] For each device, the formula is used: Association Weight = (Number of matching items between adaptation requirement type and device function / Total number of device function description items) × Empirical Coefficient

[0210] The process of obtaining the number of matching items between the adaptation requirement type and the equipment function is as follows: manually break down the core functional requirement points of the adaptation requirement type (such as the core functional requirement points of comfort requirements being temperature regulation and air volume control), retrieve all functional description items of the equipment to be evaluated in the equipment function description data set, compare the core functional requirement points with the functional description items, and count the number of consistent items.

[0211] Total number of device function description items: This refers to the total number of function description items for the device.

[0212] Iterate through all devices involved in the association weight calculation, filter out devices whose association weight is greater than or equal to a preset threshold, and organize these devices into a candidate target device set.

[0213] Substitute the corresponding adaptation requirement type of the effective final result into the three-dimensional association system and match the corresponding constraint information;

[0214] Traverse the set of core requirement keywords corresponding to the valid final results, identify keywords containing numerical values, determine the corresponding parameter type for each keyword containing numerical values ​​through semantic recognition, separate the specific numerical values ​​from the keywords, organize the above results according to the mapping relationship between parameter type and requirement numerical value, and form a set of requirement numerical values.

[0215] Compare the parameter types in the set of demand values ​​with the constraint ranges of the same parameter type in the constraint information of the valid final result:

[0216] If the required value is within the parameter range specified by the constraint information, the parameter type - required value - will be directly determined as the equipment operating parameter.

[0217] If the required value exceeds the range of parameters of the same parameter type limited by the constraint information, but the constraint information only sets a single boundary limit for the parameter, and the required value does not violate the other undefined boundary, then it is determined to be without conflict, and the parameter type - required value is retained as the equipment operating parameter.

[0218] If the required value does not intersect with the parameter range defined by the constraint information, then the boundary value of the constraint range shall be taken as the equipment operating parameter.

[0219] If the core requirement keyword set only specifies a parameter type but does not provide a specific required value for that parameter type, and the constraint information contains a limited parameter range corresponding to that parameter type, then the limited parameter range for that parameter type in the constraint information is retained as the equipment operating parameter range.

[0220] Organize all results according to the above rules, and finally output the set of device operating parameters - values / value ranges;

[0221] Iterate through each candidate target device in the candidate target device set and retrieve the function description text of each device from the device function description data set;

[0222] The number of identical words in the core requirement keyword set corresponding to the functional description text of each candidate target device and the effective final result is counted and recorded as the requirement matching word count;

[0223] The demand matching degree for each candidate target device is calculated using the formula: Demand matching degree = Number of demand matching words / Total number of words in the core demand keyword set.

[0224] The preset number of core target devices is selected, and the preset number of devices with the highest demand matching degree are selected from the candidate target device set and marked as core target devices;

[0225] A high carbon threshold is preset, and all carbon emission timestamps whose hourly carbon emission values ​​are greater than the preset high carbon threshold are extracted from the basic carbon emission data. The time periods corresponding to these timestamps are integrated and marked as high carbon periods.

[0226] From the policy constraint data, filter out policy items that are related to the expected period and the demand type of the core target equipment (such as temperature control policies corresponding to comfort needs), and extract the specific effective period of the policy item;

[0227] The intersection of the high-carbon period and the policy effective period is calculated in time dimension. The period that is both a high-carbon period and within the policy effective period is determined as the instruction execution period.

[0228] Integrate the core target equipment selected in the previous core target equipment determination step, the equipment operating parameter output from the equipment operating parameter determination step (set of values / value ranges), and the instruction execution time period determined in the instruction execution time period filtering step;

[0229] Generate device collaborative operation instructions based on the logical association of target device, parameter adjustment, and execution time period;

[0230] Furthermore, the equipment collaborative operation instructions must include three core elements:

[0231] Core target device identifier: that is, the unique identifier of the core target device in the device function description data set;

[0232] Adjustment parameter details: Based on the equipment operating parameters - value / value range collection, clarify the name of each parameter to be adjusted (such as "temperature" "air volume") and the corresponding value or value range (such as "25℃" "300~500m³ / h").

[0233] Execution period interval: This refers to the intersection of the high-carbon period and the policy effective period, as determined by the instruction execution period screening step, and is accurate to the minute level.

[0234] The equipment and policy constraint database constructed in the previous steps of constraint data processing and three-dimensional association system construction is called. The constraint parameter thresholds corresponding to the core target equipment and the matching demand type (derived from the previous "demand type determination" step) are extracted from the database. Specifically, these include: the operating condition constraint threshold of the core target equipment and the carbon emission compliance threshold in the policy constraint data.

[0235] Set the conditions for determining the violation of the instruction: If the value or range of any parameter in the adjustment parameter details of the equipment collaborative operation instruction exceeds the constraint threshold of the corresponding parameter in the equipment and policy constraint database; or if the carbon emission prediction value after the core target equipment is operated during the instruction execution period is calculated based on the prediction model of the basic carbon emission prediction steps mentioned above, and the predicted value is greater than the carbon emission compliance threshold of the policy constraint, then the equipment collaborative operation instruction is determined to be a violation instruction.

[0236] If the device collaborative operation command is determined to be a violation command, a cost optimization function is constructed based on the cross-domain data from step one:

[0237] F(P) = α·C(P) + β·Cost(P);

[0238] Wherein, F(P) is the total cost of operating the core target equipment (including carbon emission reduction costs and operating energy consumption costs).

[0239] α and β are preset weighting coefficients (α+β=1, α focuses on emission reduction and β focuses on cost, both with values ​​of 0-1).

[0240] C(P) represents the carbon emissions corresponding to parameter P, calculated based on the prediction model of the basic carbon emission prediction steps described above.

[0241] Cost(P) is the operating cost corresponding to parameter P. It is calculated based on the regional time-of-use electricity price data in the cross-domain database and the corresponding energy consumption calculation model of the core target equipment (energy consumption = power corresponding to parameter P × running time). That is, (Cost(P) = time-of-use electricity price × (power corresponding to parameter P × execution time duration).

[0242] Using the constraint parameter thresholds in the equipment and policy constraint database as boundary conditions, the minimum value of F(P) is solved by gradient descent. The parameter P corresponding to this minimum value is the compliance adjustment parameter.

[0243] Replace the adjustment parameter details of the equipment collaborative operation instructions with compliant adjustment parameters to form compliant equipment collaborative operation instructions. Send the compliant equipment collaborative operation instructions to the building equipment control system of green buildings, and the system drives the core target equipment to execute the instructions.

[0244] It should be noted that the relevance of requirements is obtained by word segmentation and keyword comparison, and a set of core requirement keywords is constructed. The appropriate requirement type is determined by combining semantic overlap, and consistency is checked with the previous related requirement type. If there is a discrepancy, the related data is updated to ensure that the requirement type is accurately determined, providing a correct basis for subsequent device and parameter matching, and avoiding process deviations caused by misjudgment of requirements.

[0245] A dataset of functional descriptions of equipment within green buildings is constructed, and core target equipment is screened by association weights and demand matching degree. Equipment operating parameters are determined by combining constraint information, high-carbon periods are extracted and policy effective periods are screened, and the intersection of the two periods is taken as the instruction execution period to generate "equipment-parameter-period" collaborative operation instructions, which solves the problem that existing technologies do not have clear operation and maintenance instructions and require manual operation.

[0246] If the equipment collaborative operation instructions violate regulations, a cost optimization function is constructed, using the constraint parameter thresholds in the equipment and policy constraint database as boundary conditions to obtain compliant adjustment parameters. This process takes into account both carbon emission reduction targets and operating costs, generates compliant equipment collaborative operation instructions, and issues them, which can avoid equipment linkage conflicts and policy violations, while controlling operation and maintenance costs and improving the feasibility and economy of the instructions.

[0247] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for predicting carbon emissions from green buildings based on multi-source energy consumption data, characterized in that: Includes the following steps: Step 1: Collect user demand signals and cross-domain data, build a dual database of demand and cross-domain data, and construct a three-level subgraph of fragment subgraph, semantic entity subgraph, and community subgraph based on it and update it dynamically; predict basic carbon emissions, match target demand signals, extract feature vectors and match them with Euclidean distance to obtain target community subgraph, verify effective correlation, generate valid final results and push them to users; Step 2: Construct a set of constraint data types to form a database of equipment and policy constraints. Match related data with timestamps as the link, and filter requirement-adaptive constraint data by combining semantic entity subgraphs. Construct a relationship system with carbon emission data, user needs, and constraint information as three-dimensional data items. Step 3: Sort the valid final results, break down and construct a set of core requirement keywords, and determine the appropriate requirement type; construct a set of equipment function description data, determine a set of candidate target equipment, analyze equipment operating parameters, screen core target equipment, and determine the instruction execution period; generate equipment collaborative operation instructions, and if there are violations, obtain compliance parameters and issue compliance instructions.

2. The method for predicting carbon emissions from green buildings based on multi-source energy consumption data according to claim 1, characterized in that: In step one, the specific process of building the requirement-cross-domain dual database is as follows: Real-time collection of demand signals from each user role; For each collected demand signal, a corresponding collection timestamp is associated with it to form a key-value pair of demand signal content and collection timestamp; Arrange all demand signal-timestamp key-value pairs in ascending order of timestamp to obtain a continuous demand time series; Acquire cross-domain data from multiple fields and mark the corresponding update timestamps; Store time-series streams and cross-domain data with timestamps separately; Using timestamps as the association key, a mapping relationship is established between the demand database and the cross-domain database, forming a dual database of demand and cross-domain data.

3. The method for predicting carbon emissions from green buildings based on multi-source energy consumption data according to claim 2, characterized in that: In step one, the specific process of constructing and dynamically updating the three-level subgraph of fragment subgraph - semantic entity subgraph - community subgraph is as follows: Raw data is extracted from the demand-cross-domain data dual databases and stored in a structured manner according to data category, core content, timestamp, and source identifier to form fragment subgraphs; Based on manually labeled samples, feature matching rules are constructed to identify user role entities, demand type entities, and data dimension entities in the fragment subgraph. Entity mapping relationships are constructed through frequency statistics and co-occurrence probability verification. Semantic entity subgraphs are formed with entities as nodes and mapping relationships as edges. Extracting the mapping relationship between user role entities and demand type entities from the semantic entity subgraph is the core of clustering. After clustering, labels are added to the demand communities and stored to form a community subgraph. Real-time monitoring of the core data update timestamps in the cross-domain database; once the preset update duration is reached, the old data is replaced, and the third-level subgraph is updated synchronously.

4. The method for predicting carbon emissions from green buildings based on multi-source energy consumption data according to claim 3, characterized in that: In step one, the specific process of generating and pushing the final verified result to the user is as follows: Call the existing green building carbon emission prediction model, input the basic parameters of the period to be predicted, and output the basic carbon emission data of the period to be predicted; Filter demand signals whose collection timestamp and the interval between the time period to be predicted are less than or equal to a preset time threshold, and establish a mapping table of the time period to be predicted and the target demand signal set. Extract the core feature parameters corresponding to the target demand signal into a vector, calculate the Euclidean distance between it and the baseline vector of the community subgraph, and select the one with the smallest distance as the target community subgraph; Traverse the target community subgraph association data to obtain valid target association relationships; Pre-set templates based on user roles, organize related data into structured information, input into a language model to generate preliminary results; After the validity check is completed and the final result is obtained, it is integrated and pushed to the corresponding user.

5. The method for predicting carbon emissions from green buildings based on multi-source energy consumption data according to claim 4, characterized in that: In step two, the specific process for creating the equipment and policy constraint database is as follows: Data on operating conditions, coupling logic, and policy constraints are obtained from building equipment management systems, equipment manufacturers' technical data, and regional housing and construction department compliance documents. A set of constraint data types is constructed based on functional attributes. The core parameters of each type of constraint data are extracted through field identification, parameter parsing, and association integration. The data is structured and stored according to constraint type, core parameters, collection timestamp, and data source to form a database of equipment and policy constraints.

6. The method for predicting carbon emissions from green buildings based on multi-source energy consumption data according to claim 5, characterized in that: In step two, the specific process of filtering the requirement adaptation constraint data is as follows: The timestamps for each carbon emission in the basic carbon emission data acquisition, the timestamps for the acquisition of target demand signals, and the timestamps for the acquisition of constraint data in the equipment and policy constraint database are all collected. If the difference between any two timestamps is less than or equal to the corresponding preset threshold, then the corresponding data is determined to be a match; Iterate through each carbon emission period timestamp in each carbon emission period timestamp, filter the constraint data in the constraint data collection timestamp that matches it, and establish a carbon emission period-constraint data mapping table; For each target demand signal, the constraint data that matches it is selected from the constraint data collection timestamp and marked as time-matched constraint data. The core parameters of the data are extracted and associated with the constraint data identifier to form a set of time-matched constraint core parameters.

7. The method for predicting carbon emissions from green buildings based on multi-source energy consumption data according to claim 6, characterized in that: In step two, the specific process of constructing a three-dimensional data item association system of carbon emission data, user requirements, and constraint information is as follows: Match the corresponding demand type entity from the target demand signal, extract all data dimension entities associated with the demand type entity, and form a set of demand-associated data dimension entities. Compare the core parameters of the time matching constraints with the feature keywords of the set, retain the consistent constraint data as the demand adaptation constraint data, and organize them into a set; and construct a mapping table of demand type - target demand signal - demand adaptation constraint data set. A mapping table of carbon emission periods associated with timestamps – constraint data mapping table of demand types – target demand signals – demand adaptation constraint data set mapping table; The system filters out core timestamps whose differences among the three timestamps are all less than or equal to a preset threshold, and binds them to corresponding carbon emissions, user needs, and constraint information to form a relational system with the core timestamps as the index and containing three-dimensional data items.

8. The method for predicting carbon emissions from green buildings based on multi-source energy consumption data according to claim 7, characterized in that: In step three, the specific process of decomposing and constructing a set of core requirement keywords from the sorted and output final results, and determining the appropriate requirement type, is as follows: Extract all valid final results, arrange them in ascending order according to the timestamps of the target demand signals they are associated with, and then decompose them one by one. For each result, segment the words to obtain an initial vocabulary set, compare the words with the preset requirement keyword library, combine the word frequency, calculate the requirement relevance, and retain qualified words to construct a core requirement keyword set; Extract the demand type entities and their exclusive keyword sets from the semantic entity subgraph, calculate the semantic overlap between the core demand keyword set and the keyword sets of each demand type entity, and select the demand type entity with the highest overlap as the adapted demand type.

9. The method for predicting carbon emissions from green buildings based on multi-source energy consumption data according to claim 8, characterized in that: In step three, the specific process of generating equipment collaborative operation instructions is as follows: Integrate the unique identifiers and functional descriptions of each device to form a set of device functional description data; For each device, the association weight formula is used to calculate the association weight of each device, and devices that meet the association weight criteria are selected to form a set of candidate target devices; Substitute the corresponding adaptation requirement type of the effective final result into the three-dimensional association system and match the corresponding constraint information; Process the set of core requirement keywords to obtain the set of requirement values, and compare the constraint information to output the set of device operating parameters - values / value ranges; Calculate the matching degree of candidate equipment requirements, and select the preset number of equipment with the highest matching degree as the core target equipment; High-carbon periods exceeding the preset high-carbon threshold are extracted from basic carbon emission data, and relevant policy effective periods are screened from policy constraint data. The intersection of the two periods is taken as the instruction execution period. Integrate core target equipment, operating parameters, and execution time periods, and generate equipment collaborative operation instructions according to the logic of target equipment - parameter adjustment - execution time period; Generate device collaborative operation instructions based on the logical association of target device, parameter adjustment, and execution time period.

10. The method for predicting carbon emissions from green buildings based on multi-source energy consumption data according to claim 9, characterized in that: In step three, the specific process of obtaining compliance parameters and issuing compliance instructions for violations is as follows: Call the equipment and policy constraint database constructed in the previous steps of constraint data processing and three-dimensional association system construction, and extract the constraint parameter thresholds corresponding to the core target equipment and the type of adaptation requirements; Set the conditions for determining whether an instruction violates the rules; If the equipment collaborative operation instruction is determined to be an illegal instruction, a cost optimization function is constructed. The cost optimization function is used to calculate the total cost of operating the core target equipment. The total cost is the sum of the carbon emissions corresponding to the parameter multiplied by a preset weight coefficient and the operating cost corresponding to the parameter multiplied by another preset weight coefficient. Using the constraint parameter threshold as the boundary condition, the minimum value of the cost optimization function is solved by gradient descent. The parameter corresponding to the minimum value is the compliant adjustment parameter of the core target equipment adjustment parameter. The adjustment parameters of the equipment collaborative operation instructions are replaced with compliant adjustment parameters to form compliant equipment collaborative operation instructions, which are then sent to the building equipment control system of green buildings. The system drives the core target equipment to execute the instructions.

Images