Model feature generation method of heating ventilation air conditioning system

Abstract

The invention belongs to the technical field of heating, ventilation and air conditioning operation and maintenance, and provides a model feature generation method of a heating, ventilation and air conditioning system, and the method comprises the steps: obtaining to-be-processed data of the heating, ventilation and air conditioning system, the to-be-processed data comprising multi-source heterogeneous data generated in the operation process of the heating, ventilation and air conditioning system; a feature field special language rule in a feature field special language rule base is called through a feature field special language interpreter, the to-be-processed data is processed into target feature data, and the target feature data is standardized feature data which has a fixed field set and a field sequence and meets the input requirement of a time sequence prediction model; generating a feature fingerprint according to the mode hash value of the target feature data and the rule hash value of the special language rule in the feature field; and the target feature data and the feature fingerprints are stored in an associated mode so as to be called by a time sequence prediction model of the heating ventilation and air conditioning system.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of HVAC operation and maintenance, and more particularly relates to a model feature generation method for a heating ventilation air conditioning (HVAC) system. BACKGROUND

[0002] In intelligent operation and maintenance of an HVAC system, time series prediction models (such as load prediction and energy consumption optimization models) are increasingly widely used, but the performance of the time series prediction models highly depends on the standardization degree of input feature data. The operation data of the current HVAC system presents a multi-source heterogeneous characteristic, leading to chaotic data semantics and non-uniform structure.

[0003] In the prior art, feature generation is mostly dependent on customized scripts or general data processing tools, and there is a lack of standardized processing solutions for the HVAC field: on the one hand, the scripts need to be frequently adjusted according to changes in device models and data formats, and have poor adaptability; on the other hand, the field set and sequence of the processed features are prone to fluctuation, and it is difficult to stably meet the model input requirements.

[0004] The above problems result in low efficiency and poor universality of HVAC system model feature generation, which restricts the reliable application of prediction models in actual operation and maintenance, and there is an urgent need for a technical solution that can realize standardized generation of features and guarantee consistency between features and models. SUMMARY

[0005] The purpose of the embodiments of the present application is to provide a model feature generation method for a heating ventilation air conditioning (HVAC) system, which aims to solve the technical problems of low efficiency and poor universality of HVAC system model feature generation in the prior art, which restricts the reliable application of prediction models in actual operation and maintenance.

[0006] To achieve the above purpose, according to a first aspect of the present application, a model feature generation method for a heating ventilation air conditioning (HVAC) system is provided, which comprises:

[0007] obtaining to-be-processed data of the HVAC system, wherein the to-be-processed data comprises multi-source heterogeneous data generated by the HVAC system during operation;

[0008] calling a feature domain specific language rule in a feature domain specific language rule library through a feature domain specific language interpreter to process the to-be-processed data into target feature data, wherein the target feature data is standardized feature data with a fixed field set and field sequence and meeting input requirements of a time series prediction model;

[0009] generating a feature fingerprint according to a mode hash value of the target feature data and a rule hash value of the feature domain specific language rule;

[0010] The target feature data is stored in association with the feature fingerprint for calling by a time series type prediction model of the HVAC system.

[0011] In a possible implementation manner, the obtaining the to-be-processed data of the HVAC system comprises:

[0012] The original data of the HVAC system is obtained, the original data comprising original reported table data of an indoor unit, original reported table data of an outdoor unit, and label data, the label data comprising energy consumption data and load data.

[0013] The original data is subjected to time synchronization processing, de-duplication processing, and basic abnormality preliminary screening processing to obtain the to-be-processed data.

[0014] In a possible implementation manner, before the to-be-processed data is processed into target feature data by calling, by a feature domain-specific language interpreter, a feature domain-specific language rule in a feature domain-specific language rule library, the method further comprises:

[0015] A semantic object model of the HVAC system is constructed, the semantic object model taking the HVAC system as a root entity and abstracting semantic fields irrelevant to devices in the HVAC system, the semantic fields comprising continuous quantity fields, discrete quantity fields, and event quantity fields.

[0016] A feature dictionary is created based on the semantic object model, the feature dictionary recording, for each semantic field, a field name, a unit, a data source, a normalization rule, an alignment rule, an aggregation rule, a missing data processing rule, a derived statistical rule, and version information.

[0017] According to the recorded content in the feature dictionary, semantic normalization rules, event-timing alignment rules, system granularity aggregation rules, missing data and abnormality processing rules, and derived statistical rules are respectively generated.

[0018] The feature domain-specific language rule library is constructed according to the semantic normalization rules, the event-timing alignment rules, the system granularity aggregation rules, the missing data and abnormality processing rules, and the derived statistical rules.

[0019] In a possible implementation manner, the feature domain-specific language rule comprises a semantic normalization rule, and processing the to-be-processed data into target feature data by calling, by a feature domain-specific language interpreter, a feature domain-specific language rule in a feature domain-specific language rule library comprises:

[0020] According to a unit conversion rule in the semantic normalization rule, data units of a continuous quantity field in the to-be-processed data are uniformly converted into a preset unit, and according to a precision uniformization rule, data precision of the continuous quantity field is adjusted to a preset precision;

[0021] According to an enumeration mapping rule in the semantic normalization rule, original enumeration values of a discrete quantity field in the to-be-processed data are mapped into standard digital codes, and the standard digital codes are converted into one-hot vectors;

[0022] According to an event type standardization rule in the semantic normalization rule, different expressions of a same type of event in an event quantity field in the to-be-processed data are uniformly classified into a standard event type.

[0023] In a possible implementation, the feature domain-specific language rule includes an event-timing alignment rule, and the processing of the to-be-processed data into the target feature data by calling the feature domain-specific language rule in the feature domain-specific language rule library through the feature domain-specific language interpreter includes:

[0024] The to-be-processed data is divided into a plurality of time windows according to a preset time interval, and the preset time interval is N hours, where N is greater than or equal to 1.

[0025] For change report data that arrives in each of the time windows with a delay, a weight of the change report data is calculated according to a time decay formula in the event-timing alignment rule.

[0026] If the weight is less than a preset weight threshold, the change report data is discarded, and if the weight is greater than or equal to the preset weight threshold, the change report data is retained.

[0027] For timing report data and change report data in each of the time windows, statistical feature data in each of the time windows is respectively calculated, and the statistical feature data includes at least one of a latest value, a mean value, a change quantity, an event count, and a duration.

[0028] In a possible implementation, the time decay formula is weight=exp(-(t-te) / τ), where t is an ending moment of a time window, te is an event occurrence moment corresponding to change report data, and τ is a decay coefficient.

[0029] In a possible implementation, the feature domain-specific language rule includes a system granularity aggregation rule, and the processing of the to-be-processed data into the target feature data by calling the feature domain-specific language rule in the feature domain-specific language rule library through the feature domain-specific language interpreter includes:

[0030] According to a weight calculation rule in the system granularity aggregation rule, weights corresponding to each normal device in the HVAC system are calculated in combination with a rated capacity, a valve opening degree, and an air volume proportion of each normal device in the HVAC system, wherein weights of offline devices and faulty devices in the HVAC system are set to zero.

[0031] For the same type of parameter data of each normal device in the HVAC system, a weighted mean value based on the weights of the normal devices, a maximum value in the same type of parameter data, and an online rate of the number of normal devices relative to the total number of devices in the system are calculated according to system granularity aggregation rules.

[0032] According to the weighted mean value, the maximum value, and the online rate, system granularity aggregation data is generated.

[0033] In a possible implementation manner, the feature domain-specific language rule includes a missing and abnormal value processing rule, and the processing of the to-be-processed data into the target feature data by the feature domain-specific language interpreter invoking the feature domain-specific language rule in the feature domain-specific language rule library includes:

[0034] According to an abnormal value processing rule in the missing and abnormal value processing rule, a reasonable range of each field data in the to-be-processed data is determined.

[0035] Data of each field data that is out of the reasonable range is clipped to a boundary value of the reasonable range, to obtain each clipped data.

[0036] The four-quartile range method is used to eliminate each of the clipped data, to eliminate extreme outliers in the clipped data.

[0037] According to a missing value processing rule in the missing and abnormal value processing rule, a forward filling method is used to fill missing values of each field data, and a maximum duration of the forward filling does not exceed a preset duration.

[0038] In a possible implementation manner, the feature domain-specific language rule includes a derived statistical rule, and the processing of the to-be-processed data into the target feature data by the feature domain-specific language interpreter invoking the feature domain-specific language rule in the feature domain-specific language rule library includes:

[0039] Based on a calculation logic in the derived statistical rule, field data that has undergone semantic normalization processing, event-timing alignment processing, or system granularity aggregation processing is used to calculate derived feature data, the derived feature data including at least one of a change rate, an accumulated value, an extreme value deviation, and a periodic fluctuation amplitude of the field data within a preset time range.

[0040] In a possible implementation manner, the method further includes:

[0041] Before the HVAC system time series prediction model performs online inference, a real-time feature fingerprint generated in the online inference process is obtained, the real-time feature fingerprint including a real-time mode hash value and a real-time rule hash value;

[0042] The real-time feature fingerprint is compared with an associated stored feature fingerprint;

[0043] If the real-time feature fingerprint is inconsistent with the associated stored feature fingerprint, the HVAC system time series prediction model is rejected to perform online inference;

[0044] If the real-time feature fingerprint is consistent with the associated stored feature fingerprint, the HVAC system time series prediction model is allowed to perform online inference.

[0045] Compared with the prior art, the embodiments of the present application have the beneficial effects that:

[0046] By obtaining the to-be-processed data of the HVAC system, the to-be-processed data including multi-source heterogeneous data generated in the running process of the HVAC system, the to-be-processed data is processed into target feature data by calling the feature domain special language rules in the feature domain special language rule library through the feature domain special language interpreter, wherein the target feature data is standardized feature data with a fixed field set and field order and meeting the input requirements of the time series prediction model; a feature fingerprint is generated according to a mode hash value of the target feature data and a rule hash value of the feature domain special language rule; and the target feature data and the feature fingerprint are associated and stored for calling by the HVAC system time series prediction model.

[0047] By using the above embodiments, the standardization degree of the AI load prediction model input features of the HVAC system can be significantly improved, the fusion efficiency of cross-brand equipment data is significantly improved, the average absolute percentage error of the model prediction is greatly reduced, the project cycle of the AI model landing is shortened, and the embodiments of the present application have significant effects in improving the landing efficiency, precision and stability of the HVAC system AI model. BRIEF DESCRIPTION OF DRAWINGS

[0048] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiments or prior art description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0049] Figure 1 is a flowchart of a model feature generation method of a HVAC system provided by the embodiments of the present application;

[0050] Figure 2 is a flowchart of an optional model feature generation method of a heating, ventilation, and air conditioning system provided by an embodiment of the present application;

[0051] Figure 3 is a flowchart of an optional model feature generation method of a heating, ventilation, and air conditioning system provided by an embodiment of the present application;

[0052] Figure 4 is a flowchart of an optional model feature generation method of a heating, ventilation, and air conditioning system provided by an embodiment of the present application;

[0053] Figure 5 is a structural diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0054] In the following description, specific details are set forth, such as particular system configurations, techniques, etc., in order to provide a thorough understanding of the present application. However, persons having ordinary skill in the art will appreciate that the present application can be practiced without these specific details. In other instances, well-known structures and techniques have not been shown in detail in order not to obscure the understanding of this application.

[0055] It should be understood that the term "comprising" as used in the specification and in the claims indicates the presence of the recited features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0056] It should also be understood that, in the description of the present application, unless otherwise stated, the " / " used in the specification and the appended claims indicates a "or" relationship of the associated objects, for example, A / B can mean A or B; "and / or" in the present application is only a description of the associated relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can mean: A alone, A and B together, B alone, of which A and B can be singular or plural. And, in the description of the present application, unless otherwise stated, "multiple" means two or more than two. "At least one of the following" or the like means any combination of the items, including any combination of single item or multiple items. For example, at least one of a, b, or c, can mean: a, b, c, a-b, a-c, b-c, or a-b-c, of which a, b, c can be single or multiple.

[0057] In addition, in order to facilitate clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, the terms "first", "second", etc. are used to distinguish the same or similar items with basically the same functions and effects. Those skilled in the art can understand that the terms "first", "second", etc. do not limit the quantity and execution order, are only used for distinction, and the terms "first", "second", etc. also do not necessarily mean different, and cannot be understood as indicating or implying relative importance.

[0058] As used in the specification and the appended claims, the term "if' can be interpreted as meaning "when" or "once" or "in response to a determination" or "in response to detecting" depending on the context. Similarly, the phrase "if it is determined" or "if [the described condition or event] is detected" can be interpreted as meaning "once it is determined" or "in response to the determination" or "upon detecting [the described condition or event]" or "in response to detecting [the described condition or event]" depending on the context.

[0059] Reference in the specification to "one embodiment" or "some embodiments" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the application. The appearances of the phrase "in one embodiment" or "in some embodiments" in various places in the specification are not necessarily all referring to the same embodiment, although it can. The terms "comprising," "including," "having," and their variations, as used in the specification, mean "including but not limited to," unless otherwise noted.

[0060] The present application provides an example of a model feature generation method of a heating, ventilation, and air conditioning system. Please refer to Figure 1 The present application provides an example of a model feature generation method of a heating, ventilation, and air conditioning system. Please refer to Figure 1 The present application provides an example of a model feature generation method of a heating, ventilation, and air conditioning system. Please refer to

[0061] S101, obtaining the to-be-processed data of the heating, ventilation, and air conditioning system, the to-be-processed data including multi-source heterogeneous data generated by the heating, ventilation, and air conditioning system during operation.

[0062] S102, calling the feature domain special language rules in the feature domain special language rule library through the feature domain special language interpreter to process the to-be-processed data into target feature data.

[0063] The target feature data is standardized feature data with a fixed field set and field order and meeting the input requirements of a time series type prediction model.

[0064] S103, generating a feature fingerprint according to the mode hash value of the target feature data and the rule hash value of the feature field special language rule.

[0065] S104, storing the target feature data and the feature fingerprint in association for calling by a time series type prediction model of a heating ventilation air conditioning system.

[0066] The model feature generation method of the heating ventilation air conditioning system provided by the embodiments of the present application will be described in detail in combination with the AI load prediction scene of the heating ventilation air conditioning (HVAC) system. Taking the HVAC system of a certain commercial complex as an example, for example, the HVAC system includes 3 outdoor units (belonging to 2 brands), 28 indoor units (covering 3 series), and is equipped with an energy consumption monitoring module and a load collection device, and there is a multi-source heterogeneous data processing demand, which can generate standardized feature data by the method provided by the embodiments to provide input for the time series type load prediction model.

[0067] In some embodiments, the data to be processed can include but is not limited to:

[0068] Raw report table data of indoor units: collect the operation monitoring data of 28 indoor units, and generate raw report tables of each indoor unit at a 15-minute cycle. The operation monitoring data includes indoor temperature, set temperature, wind speed level, operation mode (cooling / heating / air supply, etc.), valve opening degree, etc. When the operation state of the indoor unit changes (such as manual adjustment of the set temperature by the user, mode switching), trigger the change report, and generate event data including event type, parameter value before and after the change, and trigger timestamp.

[0069] Raw report table data of outdoor units: collect the operation data of 3 outdoor units, which also includes parameters such as compressor frequency, condensing temperature, outdoor environment temperature, and operation power reported at regular intervals (every 10 minutes), as well as event data reported when changes occur (such as compressor start / stop, fault alarm), and the data format can be but is not limited to JSON format and CSV format.

[0070] Label data: obtain the total power consumption (kWh) per hour through the energy consumption monitoring module of the system, and obtain the cooling / heat load value (kW) per hour through the load collection device. Such data is used as a label for model training, and is combined with device operation data to form the data content of the data to be processed.

[0071] In actual operation, the above-mentioned various data is collected through the edge gateway of the HVAC system, and is uniformly accessed to the data collection platform. The data collection platform automatically filters obviously invalid data (such as abnormal values of temperature <-20℃ or >60℃, and data with timestamps exceeding the system operation period), and forms the data to be processed.

[0072] After that, by constructing a feature domain-specific language (hereinafter referred to as DSL) rule library, and relying on the DSL interpreter to perform standardized processing, the multi-source heterogeneous data to be processed is converted into target feature data with a fixed field set and field order, the specific process is as follows:

[0073] Based on the operating characteristics and data processing requirements of the HVAC system, a DSL rule library is constructed, which includes the following multiple types of rules, each type of rule is defined in a structured DSL statement, ensuring that it can be automatically executed by the DSL interpreter:

[0074] Semantic normalization rules: used to unify the semantic caliber of data from different sources, including unit conversion, enumeration value mapping, and event type standardization.

[0075] Event-timing alignment rules: used to resolve the timing consistency problem of delayed and changed reporting data, for example, this rule defines a 1-hour preset time interval to divide the time window, for the delayed changed reporting data in each window, an exponential decay formula (weight = exp(-(t-te) / τ), where t is the end time of the window, te is the event occurrence time, τ is set to 30 minutes to control the decay rate) is used to calculate the weight, if the weight < 0.1 (preset threshold) then discard the data, otherwise keep and participate in the window statistics; at the same time, repeated data (same device, same field, same timestamp) in the window is automatically removed, and finally the latest value, mean value, change amount, event count, and duration of each window parameter are output.

[0076] System granularity aggregation rules: used to aggregate scattered data from multiple devices into system-level features, the rule definition is based on device function bit to calculate the weight, and the weight of offline or faulty devices (identified by the device online state marker) is set to 0; for each operating parameter, the weighted mean, maximum value, and online rate are uniformly output as three fixed fields, ensuring that the dimension of system-level features remains constant regardless of the number of devices (such as the addition of indoor units later).

[0077] Missing and abnormal data processing rules: used to improve data reliability, the rule defines the reasonable range of each parameter (such as the reasonable range of indoor temperature being 10-35℃, and the reasonable range of compressor frequency being 0-120Hz), and clips the data outside the range to the boundary value; the interquartile range method (IQR = Q3-Q1, extreme values < Q1-1.5IQR or > Q3+1.5IQR are removed) is used to further filter outliers; the forward filling method is used for missing values, and the maximum filling duration is not more than 2 hours (otherwise it is marked as missing); if the proportion of filled values and missing values in a field is > 30% (preset threshold), then mark the field as low confidence.

[0078] Derivative statistical rule: used to mine deep features of data, the rule defines the calculation of derived features based on basic parameters, such as 1-hour change rate of indoor temperature, 3-hour cumulative value of compressor frequency, deviation value of cooling load and outdoor temperature, etc. The derived features and the basic features jointly constitute the feature set.

[0079] In some embodiments, the DSL interpreter is started to execute automatic processing on the aforementioned to-be-processed data according to a plurality of rules contained in the DSL rule library, such as rules for semantic normalization, event-timing alignment, system granularity aggregation, missing and abnormal value processing, and sequential calling of derivative statistics:

[0080] For example, first, the semantic normalization rule is executed to uniformly convert all temperature data to ℃ units, convert discrete parameters such as wind speed level and operation mode into one-hot vectors, and classify event data into standard event types, thereby eliminating semantic differences of multi-source data; then, the event-timing alignment rule is executed to divide the processed data into 1-hour time windows, process delayed event data and eliminate duplicate data, and calculate statistical features in each window; subsequently, the system granularity aggregation rule is executed to calculate the weight of each normal device, perform weighted mean, maximum value, and online rate calculation on each parameter, and generate system-level aggregated data; then, the missing and abnormal value processing rule is executed to clip abnormal values, eliminate outliers, fill in missing values, and mark low-confidence fields; finally, the derivative statistical rule is executed to calculate derived features, which are combined with the basic aggregated features.

[0081] After the above processing, the finally generated target feature data has a fixed field set and order, and example fields include: timestamp, indoor temperature weighted mean, indoor temperature maximum value, indoor unit online rate, outdoor temperature mean value, compressor frequency weighted mean, compressor frequency maximum value, cooling load value, event count, 1-hour change rate of indoor temperature, low-confidence field mark, etc., a plurality of fixed fields, and the field order is logically arranged according to time correlation, temperature correlation, frequency correlation, load correlation, event correlation, and quality marking, fully meeting the requirements of a time-series load prediction model for standardized input.

[0082] Finally, the uniqueness of the target feature data and the processing rules is identified by calculating the feature fingerprint, which provides a basis for consistency checking of subsequent model training and inference. The specific operation is as follows: For the fixed field set and order of the target feature data, the name, data type (such as float, int, string), and field order index of each field are extracted to form structured pattern description information; the SHA-256 hashing algorithm is used to encrypt and calculate the pattern description information to obtain the pattern hash value (such as a1 b2c3d4e5f6...), which uniquely corresponds to the field structure of the target feature data. For all rules in the DSL rule library, the DSL statement of each rule is converted into a normalized syntax tree (eliminating statement format differences and retaining core logic), and all syntax trees are merged to form a unified description of the rule set; the SHA-256 hashing algorithm is also used to encrypt and calculate the description to obtain the rule hash value, which uniquely corresponds to the DSL rule set used in this data processing. The pattern hash value and the rule hash value are concatenated in order to form a feature fingerprint that binds the structure of the target feature data and the processing rules, ensuring that the same data and the same rules correspond to a unique fingerprint.

[0083] Finally, the generated target feature data and feature fingerprint are stored in association, and a calling interface is provided for the time series prediction model of the HVAC system. For example, a time series database is used as a storage carrier to create an association table of HVAC feature data and feature fingerprints. Each record in the association table contains a timestamp, target feature data (specific values of 32 fixed fields), feature fingerprint, data generation time, etc. fields, ensuring that each target feature data corresponds to its corresponding feature fingerprint, and supporting fast query by time range, feature fingerprint, etc.

[0084] When calling the time series load prediction model (such as the LSTM-based hourly load prediction model), the model first reads the target feature data and the corresponding feature fingerprint from the association table; at the same time, the model loads the DSL rule set used in the training phase, recalculates the rule hash value, and calculates the pattern hash value based on the field structure of the current input feature data to generate a real-time feature fingerprint; the real-time feature fingerprint is compared with the feature fingerprint stored in the association table. If they are consistent, it means that the structure of the current input feature data and the processing rules are consistent with the training phase, and the model performs prediction normally; if they are not consistent, an alarm is triggered to prompt that there is a deviation in the feature aperture or the processing rules, and the prediction is suspended and waits for manual verification.

[0085] Through the embodiment, the standardization degree of the input features of the AI load prediction model of the HVAC system is significantly improved, the fusion efficiency of the cross-brand equipment data is significantly improved, the average absolute percentage error of the model prediction is greatly reduced, the project cycle of the AI model landing is shortened, and the embodiment method has significant effects in improving the landing efficiency, precision and stability of the HVAC system AI model.

[0086] In a possible implementation manner, the to-be-processed data of the HVAC system is acquired, including:

[0087] The original data of the HVAC system is acquired, and the original data includes original report table data of an indoor unit, original report table data of an outdoor unit, and label data, the label data including energy consumption data and load data.

[0088] The original data is subjected to time synchronization processing, de-duplication processing and basic abnormality preliminary screening processing to obtain the to-be-processed data.

[0089] In some embodiments, the to-be-processed data of the HVAC system is not directly collected and used, but is preprocessed first to ensure that the to-be-processed data has time consistency, uniqueness and basic validity, thereby providing high-quality input for subsequent DSL rule-driven feature processing. The following will be described in detail in combination with the actual application scenario of the HVAC system of an office building (including 12 indoor units, 2 outdoor units, and a supporting intelligent monitoring terminal):

[0090] It should be understood that, in the embodiments of the present application, the collection of the original data needs to cover the core equipment and key parameters of the HVAC system to ensure that the data sources are comprehensive and can reflect the system running state, and the specific collection objects and manners are as follows:

[0091] The original report table data of the indoor unit: through the intelligent data acquisition module (supporting RS485 communication protocol) built in each indoor unit, the original report table is collected and generated at a preset period (such as 10 minutes / time), and the report table includes parameters such as indoor real-time temperature, user set temperature, wind speed level (low / medium / high / automatic), running mode (cooling / heating / dehumidifying / air supply / automatic), electronic expansion valve opening degree (0-100%), equipment running state (running / standby), etc.; at the same time, when the indoor unit changes state (such as the user adjusts the set temperature through the wire control, the mode automatically switches, the equipment fails to start and stop), the acquisition module triggers the change report to generate event data including event type-change before parameter-change after parameter-trigger timestamp-equipment number, and the event data is pushed to the system data gateway in real time in JSON format.

[0092] The original report table data of the outdoor unit: two outdoor units (for example, both are C brand different models) also generate original report tables through the built-in acquisition module at a period of 5 minutes / time, containing compressor operating frequency (0-120 Hz), outdoor environment temperature, condenser temperature, evaporator temperature, system high pressure, system low pressure, outdoor unit operating power (kW), etc. When the outdoor unit has compressor start-stop, fan speed adjustment, fault alarm (such as high pressure protection, open phase), etc. State changes trigger changes to report, generate event records consistent with the format of indoor unit event data.

[0093] Label data: Through the energy consumption monitoring instrument deployed in the power distribution room of the office building, the total power consumption (kWh) of the HVAC system is collected at 1 hour / time, as the energy consumption label data; at the same time, through the flow sensor and temperature sensor installed in the air conditioning water system pipeline, the chilled water supply and return water temperature difference and flow are collected in real time, and the hourly cooling load value (heating load value in heating season) is calculated by the formula cooling load (kW) = 1.163 x flow (m 3 / h) x supply and return water temperature difference (℃), as the load label data. Such label data and equipment operation data are associated through time stamp, and together constitute the original data.

[0094] In actual operation, all original data (indoor unit report, outdoor unit report, event data, label data) are collected through the data gateway, and are uniformly transmitted to the time series database deployed on the local server. The time series database is indexed according to the device type-device number-data type, which facilitates fast retrieval in the subsequent preprocessing stage.

[0095] In an embodiment, in order to eliminate redundancy, errors and time bias in the original data, time synchronization processing, de-duplication processing and basic anomaly preliminary screening processing are required for all original data. For example, through the NTP (Network Time Protocol) client built in the system data gateway, the time stamps of all original data are uniformly calibrated to UTC time (Coordinated Universal Time). The calibration logic is: read the original time stamp of each data, compare it with the standard NTP time obtained by the gateway, if the deviation exceeds 0.5 seconds, correct the data time stamp based on the standard time; at the same time, the deviation between the trigger time stamp and the gateway receiving time stamp in the event data is checked, if the deviation exceeds 30 seconds (may be caused by network delay), mark the event data as to be verified, and do not include it in the subsequent processing, and decide whether to use it after manual confirmation of the time validity. Through time synchronization, all original data are based on a unified time reference.

[0096] In an embodiment, due to the occasional communication retry mechanism of the data acquisition module or the gateway data receiving buffer problem, if there are duplicate records in the original data, that is, the same device, the same field, and the same timestamp correspond to multiple completely consistent parameter values, if retained, it will cause the subsequent statistical feature calculation to be distorted. Through the deduplication mechanism of the time series database, automatic processing is realized: for example, for the regularly reported table data of indoor and outdoor units, taking the device number-data acquisition timestamp-core field (such as temperature, frequency, pressure, etc.) as the combined primary key, if the same combined primary key record already exists in the database, then automatically discard the subsequently repeatedly written data; for event data, taking the device number-event trigger timestamp-event type as the combined primary key, the same repeated data elimination operation is also performed.

[0097] In some embodiments, there may be obvious outliers in the original data due to sensor failure or communication interference, which will interfere with the rule execution effect if directly entered into the feature processing link. Based on the industry operation standards and equipment technical parameters of the HVAC system, the reasonable value range of each field is preset, and each field in the original data is checked one by one: if each field is within the reasonable value range, it is marked as normal data; if any one field exceeds the reasonable value range and is abnormal for three consecutive acquisitions (excluding transient interference), it is marked as sensor failure data and triggers a device maintenance alarm; if a field only exceeds the reasonable value range for a single time, and the adjacent two acquisition data are normal, it is marked as transient abnormal data and is not excluded for the time being, but is further checked in the subsequent missing and abnormal processing rules. At the same time, missing data (such as data not collected for a period of time due to communication interruption) is marked, and the missing period and device number are recorded to provide a basis for subsequent missing value processing.

[0098] After the above preprocessing operations, the time deviation, duplicate records, and obvious abnormalities in the original data are effectively eliminated, forming the to-be-processed data with time consistency, data uniqueness, and basic effectiveness. Moreover, the to-be-processed data still retains the core information of the multi-source heterogeneous data, but meets the input requirements of the DSL interpreter and can directly enter the subsequent feature processing link.

[0099] In a possible implementation manner, as shown in Figure 2 Before the to-be-processed data is processed into target feature data by calling the feature domain specific language rule in the feature domain specific language rule library through the feature domain specific language interpreter, the method further includes:

[0100] S201, a semantic object model of the HVAC system is constructed, and the semantic object model takes the HVAC system as a root entity and abstracts semantic fields irrelevant to devices in the HVAC system.

[0101] The semantic fields include continuous quantity fields, discrete quantity fields, and event quantity fields.

[0102] S202, a feature dictionary is created based on the semantic object model, and the feature dictionary records the field name, unit, data source, normalization rule, alignment rule, aggregation rule, missing treatment rule, derived statistical rule, and version information corresponding to each semantic field.

[0103] S203, according to the record content in the feature dictionary, semantic normalization rules, event-timing alignment rules, system granularity aggregation rules, missing and abnormal treatment rules, and derived statistical rules are respectively generated.

[0104] S204, according to the semantic normalization rules, event-timing alignment rules, system granularity aggregation rules, missing and abnormal treatment rules, and derived statistical rules, a feature domain-specific language rule library is constructed.

[0105] In the embodiments of the present application, before the rule library is called by the feature domain-specific language interpreter to process data, the construction of the HVAC system semantic object model, the creation of the feature dictionary, and the generation of various feature domain-specific language (DSL) rules and the combination into a rule library are completed. The following will be described in detail in combination with the application scenario of a commercial park HVAC system (covering 3 office buildings and 2 apartment buildings, including 12 outdoor units and 86 indoor units, involving 4 brands and 6 equipment series):

[0106] Firstly, the semantic object model of the HVAC system can be understood as stripping the brand and model differences of specific equipment, abstracting the general semantic fields of the HVAC system, and forming a unified semantic framework across devices. When constructing, taking the entire HVAC system as the root entity, according to the hierarchical logic of system-device-parameter, all common operating parameters and event types of the equipment are sorted out, and semantic fields independent of specific equipment are extracted, which are classified and described as follows:

[0107] Continuous quantity field: refers to the field whose value is a continuous numerical value, reflecting the running state of the equipment or the environmental parameter. Such fields only have unit and precision differences in different equipment, and the core semantics are consistent.

[0108] Discrete quantity field: refers to the field whose value is a limited discrete value, reflecting the running mode or state selection of the equipment. Such fields mainly show enumeration value differences in different equipment, and the semantics are essentially the same.

[0109] Event quantity field: refers to the field reflecting the mutation of device state or operation trigger, which is mainly different in event name in different devices, but the core event type is consistent. For example, the set temperature change event field is abstracted, which corresponds to setTempChanged, temperature setting adjustment, target temperature modification and other events of each brand; the running mode switching event field is abstracted, which covers modeSwitched, mode change, running state conversion and other expressions; in addition, there are device start-stop, fault alarm, wind speed adjustment, electric auxiliary heating start-stop and other event quantity fields, and each field clearly defines the event trigger condition.

[0110] In addition, in the embodiment of the application, the constructed semantic object model is stored in the form of a structured document, each semantic field in the structured document includes field type (continuous quantity / discrete quantity / event quantity), core semantic definition, value range (if applicable), associated device type and other contents, and does not involve any specific brand, model device exclusive parameter information, and can be directly used as a semantic reference for subsequent feature dictionary creation.

[0111] In the embodiment of the application, it should be understood that the feature dictionary is a further refinement of each semantic field in the semantic object model, and provides clear basis for subsequent DSL rule generation by recording the specific attributes and corresponding processing rules of the field. The feature dictionary is presented in the form of a table, each row corresponds to a semantic field, and each column corresponds to an attribute information. The specific attributes and filling rules are as follows:

[0112] Field name, which can directly follow the semantic field name defined in the semantic object model (such as indoor temperature, running mode, set temperature change), to ensure consistency with the semantic model.

[0113] Unit, which is only filled for continuous quantity fields, to clearly define the standard unit of the field (such as the standard unit of indoor temperature is "℃", the standard unit of running power is "kW", and the standard unit of valve opening degree is "%"), and to note the common non-standard unit and conversion relationship.

[0114] Data source, which clearly defines the device components or collection devices corresponding to the data of the field, for example, the data source of indoor temperature is the built-in temperature sensor of the indoor unit, the data source of supply and return water temperature difference is the combined calculation of water system pipeline flow sensor and temperature sensor, and the data source of fault alarm is the fault detection module of the device controller.

[0115] Normalization rule, which defines the standardization processing rule for different types of fields. The normalization rule of continuous quantity field clearly defines the unit conversion standard and precision uniformity requirement (such as the valve opening degree data is uniformly kept to integer bits); the normalization rule of discrete quantity field clearly defines the enumeration value mapping standard and coding method; the normalization rule of event quantity field clearly defines the event type classification standard and event information extraction requirement.

[0116] Alignment rules, which specify the processing standards of the field data in the time alignment link, including the time window size (such as all fields uniformly using 1 hour as the time window), the window internal statistical method (such as the continuous quantity field in the window statistics the latest value, the mean value, the change quantity; the discrete quantity field statistics the state value with the highest proportion in the window, the state change number; the event quantity field statistics the event occurrence number, the duration in the window), the delay data processing principle (such as the event data delayed for more than 30 minutes is not included in the corresponding time window statistics).

[0117] Aggregation rules, which specify the processing standards of the field data in the system granularity aggregation link, including the weight calculation basis (such as the indoor temperature field aggregation, the rated capacity of the indoor unit and the valve opening degree are used as the weight calculation basis), the aggregation statistical index (such as the continuous quantity field aggregation output weighted mean value, maximum value; the discrete quantity field aggregation output the state with the highest frequency; the event quantity field aggregation output the total number of occurrences in the system), the offline / fault device processing method (such as the device data marked as offline or fault is not involved in the aggregation calculation).

[0118] Missing data processing rules, which specify the filling strategy when the field data is missing (such as the indoor temperature data is filled forward, and the maximum filling duration is not more than 2 hours; the running power data is filled with the historical mean value of the same time period), the missing value marking requirement (such as the filled value needs to be distinguished from the original data for subsequent quality evaluation).

[0119] Derived statistical rules, which specify the feature types that can be derived based on the field data (such as the temperature deviation value based on the indoor temperature and the set temperature; the 1-hour power cumulative value and the power change rate based on the running power; the temperature adjustment number per unit time based on the set temperature change event), the derived calculation logic (such as the temperature deviation value = indoor temperature - set temperature, the positive value indicates that the actual temperature is higher than the set temperature, and the negative value indicates that it is lower than the set temperature).

[0120] Version information, which records the creation time, update time and version number of the field attribute and corresponding rules, for subsequent version management and traceability of the rules.

[0121] Based on the attribute record of each field in the feature dictionary, the normalization rules, alignment rules, aggregation rules, missing data processing rules and derived statistical rules are extracted and converted into structured rule statements that can be executed by the DSL interpreter, forming a plurality of DSL rules, and the specific generation process is as follows:

[0122] Semantic normalization rule generation: traverse all the normalization rule records of fields in the feature dictionary, and convert the normalization rule records into DSL rule statements. For continuous quantity fields, the rule statement contains three elements of "field name-unit conversion formula-precision retention bit number"; for discrete quantity fields, the rule statement contains three elements of "field name-enumeration value mapping table-coding method"; for event quantity fields, the rule statement contains three elements of "field name-event type classification table-information extraction item"; all semantic normalization rule statements are arranged in the order of "continuous quantity-discrete quantity-event quantity" to form a semantic normalization rule set.

[0123] Event-timing alignment rule generation: according to the alignment rule records of all fields in the feature dictionary, and combining the characteristics of the HVAC system time series data, DSL rule statements are generated. The rule statement contains four elements of time window size-statistical method of each type of field-delay data processing threshold-repeated data determination standard, and the statistical indicators of continuous_stat corresponding to continuous quantity fields, discrete_stat corresponding to discrete quantity fields, and event_stat corresponding to event quantity fields in the time window are last, mean, delta, max_freq, and count, which are the latest value, the mean value, the change amount, the state value with the highest occurrence frequency, and the number of event occurrences, respectively. The rule statement is applicable to the time series alignment processing of all fields, and forms an event-timing alignment rule.

[0124] In some embodiments, DSL rule statements are generated based on the compliance rule records of all fields in the feature dictionary. The rule statement contains elements of field name-weight calculation basis and coefficient-aggregated statistical indicators-exception device processing method, and all system granularity aggregation rule statements are arranged in alphabetical order of the first letter of the field name to form a system granularity aggregation rule.

[0125] According to the missing processing rule records of all fields in the feature dictionary, and combining the industry's common abnormal value processing method, DSL rule statements are generated. The rule statement contains elements of field name-exception value determination range-exception value processing method-missing value filling strategy-filling time limit-quality mark threshold; for discrete quantity fields, the exception value determination range in the rule statement is replaced by invalid enumeration values (such as invalid enumeration values of the running mode are other values except cooling / heating / dehumidifying / air supply / automatic), and the processing method is to replace it with the last valid state value. All missing and exception processing rule statements are arranged in field type classification to form a missing and exception processing rule.

[0126] In some embodiments, the raw statistical rule records are converted into DSL rule statements by extracting the derived statistical rule records of all fields in the feature dictionary. The rule statements include elements such as base field name- derived feature name- calculation logic- statistical period, etc. All derived statistical rule statements are arranged according to the correspondence of base field- derived field to form a derived statistical rule.

[0127] The generated semantic normalization rules, event-timing alignment rules, system granularity aggregation rules, missing and abnormal data processing rules, and derived statistical rules are combined to form a feature domain-specific language rule library according to the processing order of semantic normalization, event-timing alignment, system granularity aggregation, missing and abnormal data processing, and derived statistics. Moreover, the feature domain-specific language rule library is stored in a structured XML file format, and the file header includes meta-information such as rule library version number, creation time, and applicable HVAC system type. The file body stores rule statements of each type in the above-mentioned five categories in order, and each type of rule is set with an independent label to facilitate the DSL interpreter to quickly locate and call the corresponding rule. At the same time, the rule library supports version management, and a new version number is generated and the update log is recorded each time the rule is updated (such as adding a new field or adjusting a weight coefficient), ensuring the traceability and reusability of the rule. In actual application, the rule library is deployed on the edge computing node or cloud server of the HVAC system, and the DSL interpreter can automatically perform standardized processing on multi-source heterogeneous data to be processed by reading the rule library file, thereby providing stable rule support for generating target feature data.

[0128] In one possible implementation, the feature domain-specific language rules include semantic normalization rules, such as Figure 3 As shown in the figure, the feature domain-specific language rules in the feature domain-specific language rule library are called by the feature domain-specific language interpreter to process the data to be processed into target feature data, including:

[0129] S301, according to the unit conversion rule in the semantic normalization rule, the data unit of the continuous quantity field in the data to be processed is uniformly converted into a preset unit, and the data precision of the continuous quantity field is adjusted to a preset precision according to the precision uniformization rule.

[0130] S302, according to the enumeration mapping rule in the semantic normalization rule, the original enumeration value of the discrete quantity field in the data to be processed is mapped into a standard digital code, and the standard digital code is converted into a one-hot vector.

[0131] S303, according to the event type standardization rule in the semantic normalization rule, different expressions of the same type of event in the event quantity field of the data to be processed are uniformly classified into a standard event type.

[0132] In some embodiments, the semantic normalization rule is a rule for realizing semantic unification of multi-source heterogeneous data in a feature domain-specific language (DSL) rule library. By performing standardization processing on continuous quantity fields, discrete quantity fields, and event quantity fields respectively, differences in units, enumeration expressions, and event naming of data from different brands and models of devices are eliminated, laying a foundation for subsequent time alignment, system aggregation, and other processing steps. The following describes in detail the whole process of processing the data to be processed by calling the semantic normalization rule through the DSL interpreter, in combination with the actual data processing scenario of a hotel HVAC system (e.g., covering 40 indoor units of 5 brands, 6 outdoor units, and a supporting intelligent control platform):

[0133] In some embodiments, taking the continuous quantity fields in the data to be processed as an example, which include indoor temperature, set temperature, compressor frequency, operating power, valve opening degree, and supply and return water temperature difference, due to differences in device brands, the same parameter has problems of non-uniform units and inconsistent precision retention (e.g., indoor temperature is in ℃ units for some devices and in ℉ units for some devices, operating power is retained to 1 decimal place for some devices and to 2 decimal places for some devices), and needs to be standardized processed according to the unit conversion rule and the precision unification rule in the semantic normalization rule.

[0134] The DSL interpreter first reads the configuration in the semantic normalization rule for continuous quantity fields from the rule library: in terms of preset units, it is clear that temperature parameters (indoor temperature, set temperature, outdoor environment temperature, etc.) have a preset unit of ℃, frequency parameters (compressor frequency) have a preset unit of Hz, power parameters (operating power, energy consumption data) have a preset unit of kW, opening degree parameters (valve opening degree) have a preset unit of %, and temperature difference parameters (supply and return water temperature difference) have a preset unit of ℃; in terms of precision unification rules, it is clear that temperature parameters and temperature difference parameters have a preset precision of retaining 1 decimal place, frequency parameters and power parameters have a preset precision of retaining integer places, and opening degree parameters have a preset precision of retaining integer places, and the rule includes conversion formulas for non-predefined units and predefined units (e.g., the ℉ to ℃ conversion formula is ℃=(℉-32)×5 / 9, and the horsepower (HP) to kW conversion formula is kW=HP×0.5355).

[0135] The DSL interpreter processes the continuous quantity field data according to the process of field recognition-unit detection-unit conversion-precision adjustment, so as to achieve the goal of unit unification to the preset unit and precision unification to the preset precision for all continuous quantity field data, and eliminate the problem of inconsistent numerical expressions caused by differences in device brands.

[0136] Taking the indoor temperature field as an example, the interpreter first identifies all fields in the data to be processed that are marked with indoor temperature or corresponding semantics (such as A brand device marking RoomTemp, B brand marking indoor actual temperature), and classifies them uniformly as indoor temperature fields; then it detects the unit of each piece of data, and if the unit is ℃, it directly enters the precision adjustment link, and if the unit is ℉, it calls the conversion formula in the rule to calculate (such as a certain piece of data is 55℉, converted to 25.0℃); then it adjusts the value according to the preset precision (retaining 1 decimal place), and if the original data is 25℃, it is completed as 25.0℃, and if it is 25.36℃, it is rounded to 25.4℃.

[0137] In some embodiments, the discrete quantity fields in the data to be processed include 10 parameters such as operating mode, wind speed level, device operating state, electric auxiliary heating state, etc. Different brand devices have significant differences in the enumeration value expression of the same discrete parameter, and some devices directly output text values and some output numerical codes, which need to be standardized through enumeration mapping rules and one-hot vector conversion. The DSL interpreter reads the configuration of the discrete quantity field in the semantic normalization rule from the rule library: for each discrete quantity field, the rule includes a mapping table of the original enumeration value-standard numerical code, and the one-hot vector dimension corresponding to the standard numerical code.

[0138] In the processing process, the DSL interpreter performs the steps of field matching-enumeration value mapping-one-hot vector generation: for the operating mode field, the interpreter first matches all fields in the data to be processed that express the operating mode of the device (such as A brand: Mode, B brand: operating mode selection, C brand: State), and classifies them uniformly as operating mode fields; then it reads the original enumeration value of each piece of data, and converts it to a standard numerical code according to the mapping table in the rule (such as A brand data: COOL converted to 0, B brand data heating converted to 1, etc.); finally, according to the one-hot vector dimension specified in the rule, the standard numerical code is converted to a one-hot vector (such as code 0 corresponds to vector [1, 0, 0, 0, 0], code 1 corresponds to [0, 1, 0, 0, 0], code 2 corresponds to [0, 0, 1, 0, 0], and so on).

[0139] For the wind speed level field, a piece of data for the indoor unit of B brand is medium speed, which is converted to standard code 1 and generates one-hot vector [0, 1, 0, 0]; another piece of data for the indoor unit of D brand is 03, which is converted to code 2 and generates vector [0, 0, 1, 0], and the final output of the two one-hot vectors is completely unified. Through the above processing, the originally disordered discrete quantity field data can be converted to a standardized one-hot vector that can be directly recognized by the AI model, which not only preserves the semantic information of the discrete parameters, but also eliminates the expression differences between brands, avoiding semantic understanding deviation of the model due to non-uniform enumeration values.

[0140] In another embodiment, the event quantity field in the data to be processed includes 15 parameters such as set temperature change, operation mode switching, device start / stop, fault alarm, wind speed adjustment, etc. Different brands of devices have great differences in the naming of the same type of event, and some event data only includes event name, and some also includes additional information. Therefore, the event type standardization rules are needed to realize unified classification and information standardization.

[0141] In one embodiment, the DSL interpreter reads the configuration of the event quantity field in the semantic normalization rules from the rule base: for each standard event type, all original event names that need to be classified are listed in the rules, and the core information items that need to be extracted for the event are also specified. For example, for the standard event of set temperature change, the original event names listed in the rules include setTempChanged, temperature setting adjustment, target temperature modification, TempSetChange, and parameter 1 change (note: parameter 1 of E brand device corresponds to set temperature), and the core information that needs to be extracted is specified as: event trigger timestamp, set temperature value before change, set temperature value after change, and trigger device number. For example, for the standard event of operation mode switching, the original event names include modeSwitched, operation mode switching, state conversion (note: state conversion of A brand specifically refers to operation mode switching), ModeChange, and parameter 2 change (note: parameter 2 of D brand corresponds to operation mode), and the core information that needs to be extracted is: trigger timestamp, mode before switching, mode after switching, and trigger device number. For example, for the standard event of fault alarm, the original event names include faultAlarm, fault alarm, device exception, Error, and Alarm01, and the core information that needs to be extracted is: trigger timestamp, fault device number, fault code, and fault description (if any).

[0142] In some embodiments, the DSL interpreter processes each event quantity data according to the logic of event name matching-standard type classification-core information extraction: for an event data labeled temperature setting adjustment (B brand indoor unit), the interpreter first matches its name with the original event name list corresponding to the set temperature change standard event in the rules, confirms that it belongs to this standard event type, and then extracts the four core information items of trigger timestamp (2024-05-2014:30:00), set temperature before change (24°C), set temperature after change (25°C), and trigger device number (IN-012) according to the rules; for the event data labeled TempSetChange (D brand indoor unit), it is also matched and classified as the standard event of set temperature change, and the trigger timestamp (2024-05-2015:10:00), set temperature before change (25°C), set temperature after change (26°C), and trigger device number (IN-025) are extracted. Both of them are finally classified as the event type of set temperature change, and the core information items are completely consistent.

[0143] For the fault alarm event, one piece of E brand device data is marked with Alarm01, and the note E brand Alarm01 in the rule corresponds to the fault alarm event. The interpreter classifies it as a standard event of fault alarm, extracts the trigger timestamp (2024-05-2016:45:00), fault device number (OUT-003), fault code (E03), and fault description (compressor high pressure protection). Another piece of A brand device data is marked with faultAlarm, and after classification, the trigger timestamp (2024-05-2015:00:00), fault device number (OUT-005), fault code (F05), and fault description (fan speed abnormality) are extracted. The event type name of the two is unified as fault alarm, and the information structure is completely aligned.

[0144] Through the event type standardization processing, the originally belonging to multiple different brands and named differently event data are all classified as multiple standard event types, and the core information items of the same type of event are consistent. For example, the set temperature change event no longer has multiple name expressions, and all related events include trigger timestamp, temperature before and after change, and device number information, which provides a unified semantic basis for subsequent event-time alignment links to count the number of events and the duration of events in a time window.

[0145] After the above semantic normalization processing of continuous quantity, discrete quantity, and event quantity fields, the to-be-processed data is converted from a state of multiple sources, heterogeneous, and semantic confusion to a state of unit uniformity, enumeration specification, and event standardization. The intermediate data will directly enter the subsequent event-time alignment processing link to further realize the standardization of the time sequence dimension, and finally generate the target feature data meeting the input requirements of the AI model.

[0146] In one possible implementation manner, the feature domain specific language rule includes an event-time alignment rule, and the feature domain specific language rule in the feature domain specific language rule library is called by the feature domain specific language interpreter to process the to-be-processed data into the target feature data, including:

[0147] The to-be-processed data is divided into multiple time windows according to a preset time interval, and the preset time interval is N hours, N≥1;

[0148] For the change report data that arrives in each time window with a delay, the weight of the change report data is calculated according to a time decay formula in the event-time alignment rule;

[0149] If the weight is less than a preset weight threshold, the change report data is discarded, and if the weight is greater than or equal to the preset weight threshold, the change report data is retained;

[0150] For each time window, the statistical feature data is calculated for the timing reporting data and the change reporting data, including at least one of the latest value, the mean value, the change amount, the event count, and the duration.

[0151] In some embodiments, the core goal of the event-timing alignment rule is to solve the problem of timing reporting data and change reporting data in a heating, ventilation, and air conditioning (HVAC) system, which is caused by the difference in reporting mechanism. Through time window division, delay data weight screening, and statistical feature extraction, the two types of heterogeneous time series data are standardized to a unified time granularity standardized feature, providing continuous and consistent time series input for subsequent system-level aggregation. The following describes the execution process of the rule in detail in combination with the actual operation data of a five-star hotel HVAC system (including 30 indoor units and 5 outdoor units, with a timing reporting period of 10 minutes / time and real-time change reporting triggering):

[0152] Considering that the AI load prediction model of the hotel HVAC system (used to optimize air conditioning operation strategy and reduce energy consumption) has an hourly core prediction granularity, while taking into account the integrity and timeliness of data statistics, the preset time interval N is set to 1 hour, i.e., the length of each time window is 60 minutes, and the window boundary is aligned with the natural time (e.g., 00:00-01:00, 01:00-02:00, …), avoiding the complexity of statistical logic caused by cross-day window division.

[0153] When the DSL interpreter performs window division, it first reads the timestamps of all records in the data to be processed (which have been synchronized to UTC time through pre-processing), and assigns the data to the corresponding window according to the 60-minute interval to which the timestamp belongs. For data whose timestamp falls exactly on the window boundary (e.g., 09:00:00), it is uniformly assigned to the next window (i.e., 09:00-10:00), ensuring that each data belongs to only one window without duplication or omission.

[0154] In addition, the DSL interpreter generates a unique identifier for each window (e.g., “20240610_08” represents the 08:00-09:00 window on June 10, 2024), and associates the timing reporting data and change reporting data of all devices in the window to form a time series data subset in units of windows, providing a basic data unit for subsequent delay data processing and feature calculation.

[0155] In some embodiments, in a hotel HVAC system, the change reporting data (such as user adjustment of set temperature, device failure triggered alarm) is usually transmitted to the data platform through a wireless network. Due to signal interference, gateway cache and other factors, part of the data may be delayed (i.e. the actual time of the event belongs to a certain window, but the time of data transmission to the platform has exceeded the window boundary). If such data is discarded directly, key operation events (such as temperature adjustment behavior during peak hours) may be lost; if all are retained, the time sequence logic in the window may be chaotic due to data delay. Therefore, the weight is calculated by a time decay formula, and the delayed data with actual significance to window statistics is selected.

[0156] According to the communication delay characteristics of the hotel HVAC system (historical data statistics show that 90% of the change reporting data is delayed for no more than 30 minutes), the event-timing alignment rule is configured as follows: time decay formula: weight = exp(-(t-t e ) / τ), where t is the end time of the current window (e.g. t is 09:00:00 for the "08:00-09:00" window); t e is the actual occurrence time of the event corresponding to the change reporting data (extracted from the data field event trigger timestamp); τ is the decay coefficient, set to 30 minutes (i.e. 1800 seconds), to ensure that the data delayed for 15 minutes has a higher weight, and the weight decreases rapidly after the delay exceeds 30 minutes; the preset weight threshold is 0.1, i.e. the delayed data with weight ≥ 0.1 is retained, and the data with weight < 0.1 is discarded.

[0157] Through the above weight screening, the data that is delayed but still reflects the running state in the window is retained, and the invalid data that is delayed for too long and interferes with the statistical logic is eliminated, ensuring that the change reporting data in each window has timeliness and relevance.

[0158] For each window, the DSL interpreter calculates statistical feature data according to the data type (continuous quantity, discrete quantity, event quantity), extracts core information that can reflect the running state of the device in the window, and the specific calculation logic and examples are as follows:

[0159] In some embodiments, taking indoor temperature and compressor frequency as examples, the statistical features of continuous quantity field mainly include the latest value, mean value and change quantity, which respectively reflect the state at the end of the window, the overall level and the fluctuation trend:

[0160] The latest value can be the value with the latest timestamp among all valid data in the field in the window, used to represent the instantaneous running state of the device at the end of the window. The average value is the arithmetic mean of all valid data in the field in the window, used to represent the overall running level in the window. The change amount can be the difference between the latest value of the field in the window and the data value at the start of the window, used to represent the parameter fluctuation trend in the window.

[0161] In some other embodiments, the statistical characteristics of the discrete quantity field mainly include the latest value and the value with the highest proportion, and in some scenarios, the change frequency, used to represent the mainstream running state and state switching frequency in the window.

[0162] The latest value is the enumeration value with the latest timestamp in the field in the window (which has been converted to standard encoding through semantic normalization); the value with the highest proportion is the enumeration value with the highest frequency of occurrence in the field in the window, representing the mainstream state in the window.

[0163] Taking the set temperature change and fault alarm as an example, the statistical characteristics of the event quantity field mainly include the event count and the duration, used to represent the frequency of event occurrence and the state maintenance time in the window: the event count refers to the total number of occurrences of a certain type of event in the statistical window (the same device, the same event triggers repeatedly within 1 minute is counted as 1 time, to avoid repeated counting caused by signal jitter). The duration refers to the duration from the event trigger to the end of the window or the state change again for events that need to maintain a certain state (such as device failure, running mode switching to maintain state).

[0164] Through the above statistical characteristic calculation, the timing and change reporting data in each time window are extracted into structured features such as the latest value, the average value, the change amount, the event count, and the duration, which not only retains the key information of time series data, but also realizes the unified standardization of data with different reporting mechanisms, providing standardized window-level input for subsequent system granularity aggregation processing.

[0165] In one possible implementation, the feature domain-specific language rules include system granularity aggregation rules, and the feature domain-specific language rules in the feature domain-specific language rule library are called by the feature domain-specific language interpreter to process the to-be-processed data into the target feature data, including:

[0166] According to the weight calculation rule in the system granularity aggregation rule, the weight corresponding to each normal device is calculated in combination with the rated capacity, valve opening degree, and air volume proportion of each normal device in the heating, ventilation, and air conditioning system, wherein the weights of the offline devices and the fault devices in the heating, ventilation, and air conditioning system are set to zero.

[0167] For each normal device in the HVAC system, the same parameter data is aggregated according to the system granularity aggregation rule: the weighted mean based on the weight of each normal device, the maximum value in the same parameter data, and the online rate of the number of normal devices to the total number of devices in the system are calculated.

[0168] According to the weighted mean, the maximum value and the online rate, the system granularity aggregation data is generated.

[0169] In some embodiments, the core of the system granularity aggregation rule is to eliminate the problem of device-level data dispersion caused by the difference in the number and model of HVAC (Heating, Ventilation and Air Conditioning) systems, and to generate fixed-dimension system-level features by constructing weight calculation logic combining device static attributes and dynamic running state, so as to ensure that the model input dimension does not drift with the change of device scale.

[0170] The following describes the whole process of rule execution in combination with the actual scene of a large commercial complex HVAC system (including 3 air conditioning partitions, a total of 6 outdoor units and 52 indoor units, covering office, commercial, catering and other functional areas):

[0171] Firstly, the weight of each normal device is calculated. In the HVAC system, different devices have different effects on the overall operation of the system. The weight is calculated by static rated capacity and dynamic running parameters, which reflects the importance of device function. The weight calculation formula is (w_i=0.4C_i+0.3V_i+0.3F_i, wherein: C_i is the normalized value of device rated capacity (device rated capacity divided by the maximum rated capacity of the same type of device, taking value 0-1), reflecting the static capacity proportion; V_i is the valve opening degree mean value (valve opening degree mean value in the time window divided by 100, taking value 0-1), reflecting the dynamic running load; F_i is the air volume proportion (actual air supply of the device divided by the total air supply of the same type of device, taking value 0-1), reflecting the air conditioning contribution; 0.4, 0.3, 0.3 are weight coefficients, considering the influence of static capacity and dynamic parameters.

[0172] At the same time, the rule stipulates that abnormal devices are identified through device running state field (semantic after running / standby / fault): the weight of offline devices (standby for more than 30 minutes) and fault devices is uniformly set to 0, and does not participate in aggregation. The standardization aggregation rule requires that for all the same parameter data, the weighted mean, the maximum value and the online rate of three types of indexes are calculated uniformly to ensure the fixed dimension of system-level features. According to the parameter type, the following is described:

[0173] Firstly, taking indoor temperature and compressor frequency as an example, continuous quantity parameters directly reflect the quantitative running state, and the aggregation logic focuses on the overall level, peak state and device availability:

[0174] Weighted mean: weighted average of device-level parameter mean (within time window) with device weight as coefficient.

[0175] Max: take the maximum value of all normal device parameters within the window, reflecting the peak state.

[0176] Online rate: calculated as normal device number / total system device number x 100%, reflecting device availability.

[0177] Secondly, taking the running mode as an example, the discrete quantity parameter reflects the device state selection (semantic normalization coding: refrigeration = 0, heating = 1, air supply = 2, automatic = 3), and the aggregation reflects the mainstream state through weighted voting:

[0178] Weighted mean: weighted average of device coding, the result is rounded to an integer, representing the mainstream mode of the system.

[0179] Max: take the maximum value of device coding, reflecting the extreme state selection.

[0180] Online rate: consistent with the calculation logic of continuous quantity parameters, reflecting that device availability does not change with parameter type.

[0181] Generating system granularity aggregation data integrates the weighted mean, maximum value, and online rate of various parameters into system-level data with fixed fields. Each parameter corresponds to three fields, and the dimension does not change with the number of devices. Even if the office area is newly added indoor units, only the weights and indicators need to be recalculated, and the number and names of fields remain unchanged, completely solving the problem of input dimension drift caused by changes in device scale.

[0182] In one possible implementation, the feature domain-specific language rules include missing and abnormal value processing rules, and the feature domain-specific language interpreter calls the feature domain-specific language rules in the feature domain-specific language rule library to process the to-be-processed data into target feature data, including:

[0183] According to the abnormal value processing rule in the missing and abnormal value processing rule, a reasonable range of each field data in the to-be-processed data is determined;

[0184] The data of each field data that exceeds the reasonable range is clipped to the boundary value of the reasonable range to obtain each clipped data;

[0185] The four-quartile range method is used to remove the extreme outliers in the clipped data.

[0186] According to the missing value processing rule in the missing and abnormal value processing rule, the forward filling method is used to fill the missing values of each field data, and the maximum length of the forward filling does not exceed the preset length.

[0187] In some embodiments, the core of the missing and abnormal processing rule is to correct the abnormal values and missing values in the data through a systematic method, avoiding extreme data interference with model training or feature failure due to incomplete data. The rule ensures the accuracy and integrity of the final generated target feature data through progressive processing of reasonable range definition, boundary clipping, outlier removal, and missing value filling. The following explains the rule execution process in detail in the context of actual data processing of a commercial building HVAC system (including 15 indoor units and 3 outdoor units, mainly monitoring temperature, pressure, frequency, etc.):

[0188] The missing and abnormal processing rule first sets the reasonable value range of each field as the basis for judging whether the data is abnormal, according to the equipment technical manual, industry operation standard, and historical data distribution characteristics for different types of monitoring parameters. The specific range setting needs to consider the physical meaning and actual running scenario of the parameter:

[0189] For continuous quantity parameters, the reasonable range of indoor temperature is set to 16-30℃ (not less than 16℃ for winter heating, not higher than 30℃ for summer cooling); the reasonable range of compressor frequency is 0-120Hz (the highest rated frequency of the equipment is 120Hz, and the stop frequency is 0Hz), etc. For discrete quantity parameters after semantic normalization (such as the encoding of the running mode is 0-4), the reasonable range is directly limited to the enumeration value set (0-4), and the encoding outside this range (such as 5 or -1) is determined as abnormal. The reasonable range needs to be updated regularly (every quarter) according to the system running state, for example, the reasonable upper limit of outdoor environment temperature can be temporarily adjusted from 45℃ to 50℃ during the extreme high temperature in summer to avoid misjudgment.

[0190] For abnormal data outside the above reasonable range, the rule adopts a boundary clipping strategy (rather than directly removing) to correct the abnormal values to the boundary values of the reasonable range, preserving the time sequence continuity of the data. The specific processing logic is: if the data value is higher than the upper limit of the reasonable range, clip it to the upper limit value; if it is lower than the lower limit of the reasonable range, clip it to the lower limit value. Boundary clipping not only eliminates obviously unreasonable extreme values, but also avoids time sequence breakage caused by removing data, especially suitable for glitch data generated by sensor transient fluctuations in HVAC systems.

[0191] The data after boundary clipping may still have pseudo-normal extreme outliers (although within a reasonable range, but significantly deviate from the overall distribution of data), which need to be further screened and removed by the interquartile range (IQR) method. The processing steps set in the rules are: for the clipped data of each field, calculate the first quartile (Q1, 25% quantile) and the third quartile (Q3, 55% quantile); Calculate the interquartile range IQR = Q3-Q1; Set the outlier judgment threshold: lower limit = Q1-1.5*IQR, upper limit = Q3+1.5*IQR; Remove all data outside the range [lower limit, upper limit], and mark as extreme outliers, which are not involved in subsequent calculations.

[0192] After exception handling, there may be missing values in the data due to the removal of outliers or failure of original collection. The rules use the forward filling method (LOCF) to fill in the missing values, and limit the maximum filling duration to ensure data validity. The specific execution logic is:

[0193] Forward filling method: fill the current missing position with the last valid data value before the missing value, for example, the temperature data of a certain indoor unit at 09:10 is missing, and the previous valid data is 24℃ at 09:00. Fill in 24℃.

[0194] Maximum filling duration: the maximum filling duration is preset to 2 hours in the rules (which can be adjusted according to the importance of parameters), that is, the part with continuous missing duration exceeding 2 hours is not filled in, marked as long-term missing, and needs to be noted in the subsequent feature description. At the same time, all filled values need to be marked with a special mark (such as suffix "_F") to distinguish from original valid data.

[0195] Through the above processing, the abnormal values in the HVAC system data to be processed are corrected or removed, and the missing values in the data to be processed are reasonably filled in. The final target feature data not only retains the time sequence characteristics of the original data, but also eliminates the technical problems of obvious noise and data breakage.

[0196] In one possible implementation, the feature domain-specific language rule includes a derived statistical rule, and the feature domain-specific language rule in the feature domain-specific language rule library is called by the feature domain-specific language interpreter to process the data to be processed into the target feature data, including:

[0197] Based on the calculation logic in the derived statistical rule, the field data after semantic normalization processing, event-timing alignment processing or system granularity aggregation processing is calculated to derive feature data, and the derived feature data includes at least one of the change rate, cumulative value, extreme value deviation, and periodic fluctuation amplitude of the field data within a preset time range.

[0198] In some embodiments, the derived statistical rule extracts more business value derived features by performing secondary calculations on the base field data, making up for the lack of information in the original data in terms of trend, accumulation, volatility, etc. Based on the standardized data after semantic normalization, event-timing alignment or system granularity aggregation, the derived features are generated according to the pre-designed calculation logic, providing more accurate feature support for HVAC system load prediction, fault diagnosis and other scenarios. The following will combine the actual data processing scene of the HVAC system of a smart park (covering office, R&D, conference and other functional areas, including 20 indoor units and 4 outdoor units) to explain the rule execution process in detail:

[0199] The derived statistical rule has four types of core derived feature calculation logic for different types of base fields. The source of the base data is the standardized data after pre-processing (semantic normalization, event-timing alignment or system granularity aggregation):

[0200] Rate of change: reflects the change speed of the parameter in the time dimension, calculated based on the time window data of the continuous quantity field; Cumulative value: reflects the total amount of the parameter accumulated in a period of time, based on the time series data of the continuous quantity field; Extreme value deviation: measures the deviation of the actual value of the parameter from the theoretical extreme value, calculated based on the real-time value of the continuous quantity field and the preset threshold; Periodic fluctuation amplitude: describes the fluctuation range of the parameter in the periodic interval, based on the periodic data statistics of the continuous quantity or discrete quantity field.

[0201] Based on the above four types of derived features, the DSL interpreter performs secondary processing on the standardized base data according to the calculation logic defined in the rule, as follows:

[0202] Taking the compressor frequency rate of change and the indoor temperature rate of change as examples, the rate of change is used to capture the short-term trend of the parameter, and the calculation formula is (current window mean - previous window mean) / time interval, with the time interval being consistent with the window length (1 hour), and the result being expressed in units / hour.

[0203] Taking the cumulative value of the running power cumulative value and the set temperature change frequency cumulative value as examples, the cumulative value is used to measure the total amount of the parameter in a period of time, and different calculation methods are used according to the field type: continuous quantity field (such as running power): the cumulative value is the sum of the power mean values of the current window and the previous N windows multiplied by the window length. In the rule, N is set to 23 by default (i.e. 24-hour cumulative). Event quantity field (such as set temperature change): the cumulative value is the sum of the event counts of the current window and the previous N windows. The cumulative value calculation supports flexible adjustment of N value (such as 8-hour working period cumulative), meeting the statistical needs of different scenarios.

[0204] Taking the extreme value deviation as an example, the extreme value deviation is used to evaluate the deviation of the parameter from the theoretical extreme value, and the calculation formula is (actual value-safety extreme value) / safety extreme value*100%, and the safety extreme value is taken from the reasonable range boundary in the missing and abnormal processing rules.

[0205] Taking the periodic fluctuation amplitude as an example, the periodic fluctuation amplitude is used to analyze the fluctuation range of the parameter in the periodic interval, and the calculation formula is the maximum value in the period-the minimum value in the period, and the period can be set as day, week, month. The fluctuation amplitude can further derive the fluctuation deviation rate (current fluctuation amplitude / historical average fluctuation amplitude*100%) in combination with the historical same period data, which is used to identify abnormal fluctuation (such as the daily fluctuation amplitude of 8℃ in a week, the historical average is 4℃, the deviation rate is 200%, which prompts that there may be equipment abnormality).

[0206] The derived features generated by the above calculation, together with the basic field features, form the target feature data, forming a double-layer feature system of basic features and derived features. The derived features expand the information density of the original data from the trend, total amount, safety boundary, periodicity and other dimensions. Through the processing of the derived statistical rules, the target feature data not only retains the basic information of the original data, but also has a deep analysis ability for the running state of the HVAC system, providing more predictive input features for the subsequent AI model (such as load prediction model, energy consumption optimization model).

[0207] In a possible implementation manner, as shown in Figure 4 the method further includes:

[0208] S401, before the time series prediction model of the heating ventilation air conditioning system performs online inference, real-time feature fingerprints generated in the online inference process are obtained, and the real-time feature fingerprints include real-time mode hash values and real-time rule hash values.

[0209] S402, the real-time feature fingerprints are compared with the associated stored feature fingerprints.

[0210] S403, if the real-time feature fingerprints are inconsistent with the associated stored feature fingerprints, the time series prediction model is rejected to perform online inference.

[0211] S404, if the real-time feature fingerprints are consistent with the associated stored feature fingerprints, the time series prediction model is allowed to perform online inference.

[0212] In some embodiments, to ensure the reliability of the online inference results of the timing type prediction model (such as load prediction, fault warning model) of the HVAC system, the consistency of the feature generation logic is verified through a feature fingerprint comparison mechanism to prevent abnormal model output caused by changes in feature processing rules and data mode deviation. Through the comparison of real-time fingerprints and baseline fingerprints, the pre-check of the online inference process is realized.

[0213] It should be understood that the real-time feature fingerprint is the digital signature of the feature data generation logic during online inference, including a real-time mode hash value and a real-time rule hash value, which respectively reflect the structural characteristics and generation rule characteristics of the feature data:

[0214] The real-time mode hash value is calculated based on the meta information of the target feature data generated during online inference, used to verify the structural consistency of the feature, including: a feature field set; the data type of each field (such as floating point type, integer type, enumeration code); feature dimension (such as fixed 36 field dimensions after system level aggregation); key statistical quantity snapshot (such as hash digest of mean and standard deviation of all continuous features). The calculation method is: the above meta information is spliced into a string in a predetermined order, and a 32-bit hash value is generated through SHA-256 algorithm as the real-time mode hash value.

[0215] Based on the feature field specific language rules actually executed during online inference, it is used to verify the consistency of the rule logic, including: the complete configuration of the semantic normalization rule (unit conversion formula, enumeration mapping table, event standardization list); the parameters of the event-timing alignment rule (time window size, decay coefficient, weight threshold); the weight calculation formula and coefficient of the system granularity aggregation rule; the reasonable range and filling strategy of the missing and abnormal processing rule; the derivation feature calculation logic of the derived statistical rule. The calculation method is: the text description of all rules (remove annotations and spaces) is sorted and spliced according to the rule type, and a 32-bit hash value is generated through SHA-256 algorithm as the real-time rule hash value.

[0216] The stored feature fingerprint is the baseline fingerprint fixed before the model goes online, for example, after the timing type prediction model completes offline training and passes the effect verification, before it is formally deployed online, the feature data and rules used during training are used to generate; the content structure includes a baseline mode hash value (corresponding to the feature meta information of the training data) and a baseline rule hash value (corresponding to the feature processing rules used during training); finally, it is stored in association with the model file in the model repository, forming a one-to-one mapping between the model and the fingerprint.

[0217] In some embodiments, before online inference, the DSL interpreter triggers a fingerprint comparison process, generates feature data of the current inference batch in real time, synchronously calculates a real-time mode hash value and a real-time rule hash value; reads a benchmark mode hash value and a benchmark rule hash value associated with the model from a model warehouse; and performs double comparison: if the real-time mode hash value ≠ the benchmark mode hash value, it indicates that the feature structure has changed (such as adding / deleting a field, changing a data type); if the real-time rule hash value ≠ the benchmark rule hash value, it indicates that the feature processing rule is modified (such as adjusting a unit conversion formula, changing a weight coefficient).

[0218] If the real-time feature fingerprint is consistent with the associated stored feature fingerprint, the model is allowed to perform online inference; if the real-time feature fingerprint is inconsistent with the associated stored feature fingerprint, it is determined that the feature logic has deviated, the inference request is rejected, and an alarm is triggered (such as being pushed to an operation and maintenance platform, prompting that the feature fingerprint does not match, and the inference is terminated).

[0219] When the fingerprint comparison is inconsistent, record the abnormal details (including the real-time fingerprint, the benchmark fingerprint, and the inconsistent items) to an audit log for problem tracing; suspend the current inference task, and reserve the abnormal feature data for offline analysis; notify the model maintenance personnel to check the difference reason. If it is indeed a reasonable change (such as adjusting the feature processing rule due to business needs), retrain the model based on the new rule to generate a new benchmark fingerprint; submit a fingerprint update application, and after the application is approved, store the new fingerprint and the upgraded model in association; the online system loads the new model and the new fingerprint, and subsequent inference is based on the new benchmark for comparison.

[0220] Through the strong consistency check of the hash value, it is ensured that the feature logic of online inference and model training is homologous, which avoids the prediction accuracy decline caused by feature drift from the source, and is especially suitable for scenes where the HVAC system has high requirements for prediction reliability.

[0221] It should be understood that the size of the serial number of each step in the above embodiments does not mean the order of execution, and the execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0222] The electronic device provided in the embodiments of the present application further includes one or more processors and a memory;

[0223] The memory is coupled to the one or more processors, and the memory is configured to store computer program code including computer instructions, and the one or more processors invoke the computer instructions to enable the electronic device to perform the model feature generation method of the HVAC system as described above.

[0224] Figure 5A structural schematic diagram of an electronic device is provided in the embodiments of the present application. The electronic device 500 can be a mobile phone, a smart screen, a tablet computer, a wearable electronic device, a vehicle-mounted electronic device, an augmented reality (AR) device, a virtual reality (VR) device, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), a projector, or a server, a memory, a base station, or a communication device, or a smart car. The embodiments of the present application do not make any limitation on the specific type of the electronic device.

[0225] The memory 501 can be used to store computer software programs 502 and modules, and the processor 503 can execute various function applications and data processing of the electronic device by running the software programs and modules stored in the memory 501. The memory 501 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, at least one application program required by a function (such as a sound playing function, an image playing function, etc.), etc.; and the data storage area can store data created according to the use of the electronic device (such as audio data, a phone book, etc.), etc. In addition, the memory 501 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other volatile solid-state memory device.

[0226] The processor 503 can include one or more of a central processor, an application processor (AP), a baseband processor, etc. The processor can be the nerve center and command center of the wireless router. The processor 503 can generate operation control signals according to instruction operation codes and timing signals, and complete the control of fetching and executing instructions. The memory 501 can be used to store computer executable program codes, and the executable program codes include instructions. The processor 503 can execute various function applications and data processing of the network device by running the instructions stored in the memory. The memory 501 can include a program storage area and a data storage area, such as data of a sound signal to be played, etc. For example, the memory can be a double data rate synchronous dynamic random access memory (DDR) or a flash memory (Flash), etc.

[0227] The embodiments of the present application also provide a computer readable storage medium, wherein the computer readable storage medium stores computer instructions; when the computer readable storage medium runs on an electronic device, the electronic device executes the model feature generation method of the heating ventilation air conditioning system shown in the foregoing embodiments.

[0228] The computer instructions can be stored in or transferred from one computer-readable medium to another computer-readable medium, such as from one website, computer, server, or data center to another website, computer, server, or data center, through wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) means. The computer-readable medium can be any available medium accessible by a computer or data storage device, such as one or more servers, data centers, etc., integrated with the medium. The available medium can be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium, or a semiconductor medium (such as a solid state disk (SSD)), etc.

[0229] The embodiments of the present application also provide a computer program product containing computer instructions, which, when the computer program product runs on an electronic device, enables the electronic device to execute the model feature generation method of the warm air conditioning system shown in the foregoing.

[0230] The computer storage medium and the computer program product provided by the embodiments of the present application are used to execute the method provided in the foregoing, and thus the beneficial effects that can be achieved by the computer storage medium and the computer program product can refer to the beneficial effects of the method provided in the foregoing, which will not be described herein again.

[0231] In the embodiments described above, all or part of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present application are generated. The computer can be a general purpose computer, a special purpose computer, a computer network or other programmable apparatus. The computer instructions can be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, such as from a website site, computer, server or data center to another website site, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) mode. The computer readable storage medium can be any available medium that can be accessed by a computer, or a data storage device such as a server, data center, etc. integrated with one or more available media. The storage medium can be a magnetic disk, an optical disk, a read-only memory (Rom), a random access memory (RAM), a flash memory, a hard disk drive (HDD) or a solid state drive (SSD), etc. The storage medium can also include a combination of the above types of memory.

[0232] In the above embodiments, the description of each embodiment has its own focus, and the parts not described or recorded in detail in a certain embodiment can be referred to the relevant description of other embodiments.

[0233] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in conjunction with the embodiments applied herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are executed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0234] In the embodiments provided by the present application, it should be understood that the disclosed apparatus / network device and method can be implemented in other manners. For example, the embodiments of the apparatus / network device described above are merely illustrative. For example, the division of the modules or units is merely logical function division, and there can be another division manner in actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between the units can be indirect couplings or communication connections through some interfaces, devices or units, and can be electrical, mechanical or in other forms.

[0235] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., can be located in one place, or can be distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiments.

[0236] The above-described embodiments are merely used to illustrate the technical solutions of the present application, but not limit the present application; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: the technical solutions recorded in the foregoing embodiments can still be modified, or some technical features can be replaced by equivalent replacements; and these modifications or replacements do not make the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A method for generating model features of a heating, ventilation, and air conditioning system, characterized in that, include: Acquire unprocessed data from the HVAC system, including multi-source heterogeneous data generated during the operation of the HVAC system; The data to be processed is processed into target feature data by calling the feature domain-specific language rules in the feature domain-specific language rule base through the feature domain-specific language interpreter. The target feature data is standardized feature data with a fixed set of fields and field order, and meets the input requirements of time series prediction models. A feature fingerprint is generated based on the pattern hash value of the target feature data and the rule hash value of the feature domain-specific language rule; The target feature data and the feature fingerprint are associated and stored for use by the time-series prediction model of the HVAC system.

2. The method according to claim 1, characterized in that, The acquisition of unprocessed data from the HVAC system includes: Obtain the raw data of the HVAC system, including the raw report data of the indoor unit, the raw report data of the outdoor unit, and the tag data, wherein the tag data includes energy consumption data and load data; The original data is processed by time synchronization, deduplication, and basic anomaly screening to obtain the data to be processed.

3. The method according to claim 1, characterized in that, Before processing the data to be processed into target feature data by calling feature domain-specific language rules in the feature domain-specific language rule base through a feature domain-specific language interpreter, the method further includes: Construct a semantic object model of the HVAC system. The semantic object model takes the HVAC system as the root entity and abstracts semantic fields that are unrelated to the equipment in the HVAC system. The semantic fields include continuous quantity fields, discrete quantity fields, and event quantity fields. A feature dictionary is created based on the semantic object model. The feature dictionary records the field name, unit, data source, normalization rule, alignment rule, aggregation rule, missing data handling rule, derived statistics rule, and version information corresponding to each semantic field. Based on the records in the feature dictionary, semantic normalization rules, event-timing alignment rules, system granularity aggregation rules, missing and anomaly handling rules, and derived statistical rules are generated respectively. Based on the semantic normalization rule, the event-time alignment rule, the system granularity aggregation rule, the missing and anomaly handling rule, and the derived statistical rule, the feature domain-specific language rule library is constructed.

4. The method according to any one of claims 1 to 3, characterized in that, The feature domain-specific language rules include semantic normalization rules. The step of processing the data to be processed into target feature data by calling the feature domain-specific language rules in the feature domain-specific language rule base through a feature domain-specific language interpreter includes: According to the unit conversion rules in the semantic normalization rules, the data units of the continuous quantity fields in the data to be processed are uniformly converted to preset units, and the data precision of the continuous quantity fields is adjusted to preset precision according to the precision unification rules. According to the enumeration mapping rule in the semantic normalization rule, the original enumeration values ​​of the discrete fields in the data to be processed are mapped to standard digital codes, and the standard digital codes are converted into one-hot vectors. According to the event type standardization rule in the semantic normalization rule, the same type of events with different expressions in the event quantity field of the data to be processed are uniformly classified into standard event types.

5. The method according to any one of claims 1 to 3, characterized in that, The feature domain-specific language rules include event-time alignment rules. The process of processing the data to be processed into target feature data by calling the feature domain-specific language rules in the feature domain-specific language rule library through the feature domain-specific language interpreter includes: The data to be processed is divided into multiple time windows according to a preset time interval, where the preset time interval is N hours and N≥1; For each delayed change report data within the time window, the weight of the change report data is calculated according to the time decay formula in the event-timing alignment rule; If the weight is less than a preset weight threshold, the change report data is discarded; if the weight is greater than or equal to the preset weight threshold, the change report data is retained. For the timed reported data and change reported data within each time window, statistical characteristic data for each time window are calculated. The statistical characteristic data includes at least one of the following: recent value, mean, change, event count, and duration.

6. The method according to claim 5, characterized in that, The time decay formula is weight = exp(-(t-te) / τ), where t is the end time of the time window, te is the time when the event corresponding to the reported change data occurs, and τ is the decay coefficient.

7. The method according to any one of claims 1 to 3, characterized in that, The feature domain-specific language rules include system-granularity aggregation rules. The step of processing the data to be processed into target feature data by calling the feature domain-specific language rules in the feature domain-specific language rule library through a feature domain-specific language interpreter includes: According to the weight calculation rules in the system granularity aggregation rules, and combined with the rated capacity, valve opening degree and air volume ratio of each normal device in the HVAC system, the weight corresponding to each normal device is calculated, wherein the weight of offline devices and faulty devices in the HVAC system is set to zero. For the same type of parameter data of each normal device in the HVAC system, the following are calculated according to the system granularity aggregation rules: the weighted average value obtained based on the weight of each normal device, the maximum value among the same type of parameter data, and the online rate of the number of normal devices to the total number of devices in the system; Based on the weighted average, the maximum value, and the online rate, aggregated data at the system granularity is generated.

8. The method according to any one of claims 1 to 3, characterized in that, The feature domain-specific language rules include rules for handling missing and exception handling. The step of processing the data to be processed into target feature data by calling the feature domain-specific language rules from the feature domain-specific language rule base through a feature domain-specific language interpreter includes: According to the outlier handling rules in the missing and anomaly handling rules, determine the reasonable range of each field data in the data to be processed; Data in each field that exceeds the reasonable range is cropped to the boundary value of the reasonable range to obtain the cropped data. The interquartile range method is used to remove extreme outliers from the cropped data. According to the missing value handling rules in the missing and anomaly handling rules, the missing values ​​of each of the field data are filled by the forward filling method, and the maximum duration of the forward filling does not exceed the preset duration.

9. The method according to any one of claims 1 to 3, characterized in that, The feature domain-specific language rules include derived statistical rules. The step of processing the data to be processed into target feature data by calling the feature domain-specific language rules in the feature domain-specific language rule library through a feature domain-specific language interpreter includes: Based on the calculation logic in the derived statistical rules, derived feature data is calculated for the field data after semantic normalization, event-time alignment, or system granularity aggregation. The derived feature data includes at least one of the following: the rate of change of the field data within a preset time range, the cumulative value, the extreme value deviation, and the periodic fluctuation amplitude.

10. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Before the time-series prediction model of the HVAC system is subjected to online inference, the real-time feature fingerprint generated during the online inference process is obtained. The real-time feature fingerprint includes real-time pattern hash value and real-time rule hash value. The real-time feature fingerprint is compared with the associated stored feature fingerprint; If the real-time feature fingerprint is inconsistent with the associated stored feature fingerprint, then the time-series prediction model is rejected from performing online inference. If the real-time feature fingerprint matches the associated stored feature fingerprint, then the time-series prediction model is allowed to perform online inference.

Images