Equipment data intelligent processing method based on strategy driving

Abstract

The invention relates to an equipment data intelligent processing method based on strategy driving, and the method achieves the efficient standardization processing of original data messages reported by different equipment. The method comprises the following steps that: equipment uploads an original data message, wherein the original data message comprises an equipment ID (Identity) and a data item consisting of a plurality of field names and field values; the equipment type is inquired according to the equipment ID, bound child node strategies in a strategy tree are obtained according to the equipment type, the strategy tree comprises father node strategies and child node strategies, the father node strategies are bound with the same equipment series to which the multiple equipment types belong, each father node strategy has multiple child node strategies, and the child node strategies are bound with the same equipment series to which the multiple equipment types belong; the child node strategy automatically inherits the father node strategy and supports modification; and processing the data item by adopting a child node strategy to obtain a standardized field name, a standardized field value or a temporary null value.

Description

Technical Field

[0001] This application relates to the field of IoT device data management technology, and in particular to a policy-driven intelligent processing method for device data. Background Technology

[0002] In modern Industrial Internet of Things (IIoT) systems, the types of connected devices are diverse (such as sensors, controllers, and machine tools from different manufacturers and models), resulting in data with significant heterogeneity. This manifests as large differences in field naming, inconsistent units, and diverse data formats, greatly increasing the difficulty of data standardization, integration, and analysis. Existing technologies for handling such heterogeneous device data mainly suffer from the following representative solutions and their inherent defects. Some solutions adopt a unified verification method based on static templates, that is, pre-define fixed field mapping templates and force all device data to be verified and converted according to these templates. Undefined or mismatched fields are often discarded or filled with default values ​​(such as null). This approach leads to poor data consistency, failing to effectively unify the different field names (such as temp, TEMP, temperature value) or units used by different devices for the same physical quantity, resulting in a chaotic standardized data model. At the same time, it has low flexibility; adding new devices or changing fields requires manual modification of the template, resulting in high adaptation costs and a high risk of information loss. Other solutions, in order to overcome the shortcomings of static templates, introduce manually maintained strategy rules (such as field mapping, unit conversion, and missing value handling rules), but these require manual configuration and maintenance by the administrator. As equipment scales up, maintenance workload increases dramatically, costs become high, and errors are more likely to occur. When data characteristics change (such as a sudden increase in field missing rates), response is delayed. Adding new equipment types often requires almost a complete reconfiguration of strategies, resulting in poor reusability and insufficient scalability. Furthermore, existing technologies address the missing data problem with missing value imputation schemes based on a single prediction model, i.e., training and deploying a unified prediction model applicable to all or a specific type of equipment. However, this method ignores the significant differences in data distribution, operating environment, and sensor characteristics among different equipment types, leading to limited prediction accuracy.

[0003] A search of existing technical literature revealed a patent application (application number 202110743557.4) entitled "A Method and Device for Standardizing Text Data." This patent involves determining the target data type corresponding to at least one piece of original text data to be processed; then, calling a target data dictionary corresponding to the target data type, wherein the target data dictionary includes at least one classification field and one or more preset data objects corresponding to each classification field; finally, standardizing the at least one piece of original text data based on the target data dictionary to obtain standardized data structure data corresponding to the at least one piece of original text data. However, this patent suffers from problems such as difficulty in processing data uploaded from different devices in real time and efficiency, and lack of missing value handling. Summary of the Invention

[0004] Therefore, it is necessary to provide a policy-driven intelligent processing method for device data to address the above-mentioned technical problems and achieve efficient and standardized processing of raw data packets reported by different devices.

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution: This invention provides a policy-driven intelligent processing method for device data, the method comprising: S1: The device uploads a raw data packet, which includes a data item consisting of a device ID and multiple field names and field values; S2: Query the device type based on the device ID, and obtain the bound child node policies in the policy tree based on the device type. The policy tree includes parent node policies and child node policies. The parent node policy is bound to the same device series to which multiple device types belong. Each parent node policy has multiple child node policies. The child node policies automatically inherit the parent node policies and support modification. S3: Process the data items using a child node strategy to obtain standardized field names, standardized field values, or temporary null values.

[0006] Preferably, the child node strategy includes: FIELD rule module, MATCH rule module, ACTIONS rule module, and MODEL rule module; The FIELD rules module includes standardized field names; The MATCH rules module includes a list of field aliases and a list of unit keywords; The ACTIONS rules module includes functions for handling the presence of field values ​​and functions for handling the absence of field values; The MODEL rules module includes a list of feature extraction functions.

[0007] Preferably, the child node strategy automatically inherits the parent node strategy and supports modification, including: Rule modules whose child node policies are not defined inherit from the parent node policies; The rule modules defined by the child node strategy override the corresponding rule modules of the parent node strategy.

[0008] Preferably, step S3 includes: S301: Use the FIELD rule module and the MATCH rule module to match the field names in the data items with the standardized field names. If the match is successful, the standardized field names are obtained. S302: Determine if a field value exists in the data item. If it exists, execute the field value existence processing function in the ACTIONS rule module to obtain the standardized field value. If it does not exist, execute the field value missing processing function in the ACTIONS rule module to obtain a temporary null value.

[0009] Preferably, step S301 further includes: If a match fails, the field names in the data item are processed according to predefined rules, which include: ignoring, logging, and default processing.

[0010] Preferably, step S302 further includes: Data is collected using the MODEL rules module to obtain feature data. The device type, standardized field names, feature data and timestamp are combined to form structured data and then written into the time series database. The feature data includes: ambient temperature features and device status features. Based on the aggregation and statistical capabilities of time-series databases, temporary null values ​​are statistically analyzed, and a missing rate index is generated in real time. If the missing rate index reaches the preset trigger condition, structured data is used as input to execute field value prediction model training, and a trained field value prediction model is obtained. The trained field value prediction model is encapsulated into a standardized function and the field value missing handling function is updated. Execute the missing field value handling function in the ACTIONS rules module to obtain the standardized field value and replace the temporary null value.

[0011] Preferably, the missing rate index is displayed in the form of a heatmap.

[0012] Preferably, the preset triggering conditions are written using aggregated metrics calculated in real time from a time-series database. The aggregated metrics include: device type, standardized field name, and missing rate metric.

[0013] Preferably, before training the field value prediction model, the method further includes selecting a field value prediction model based on the type of the field value to be predicted in the data item. If the type of the field value to be predicted is numerical, the LightGBM regression model is selected; if the type of the field value to be predicted is categorical, the XGBoost classification model is selected.

[0014] Preferably, the field value prediction model is trained using an incremental learning mode.

[0015] Compared with the prior art, the beneficial effects of the present invention are: This invention provides a policy-driven intelligent device data processing method. By constructing a dynamic policy inheritance tree, the method utilizes the rule characteristics of child node policies inheriting parent node policies. When adding new device types, existing rule bases can be reused. For example, when adding devices of the same series, only the parent node policy needs to be bound and the unit conversion rules need to be fine-tuned, without rewriting the complete policy. This reduces repetitive configuration operations and improves the efficiency of large-scale device access. The child node policies handle the problem of field name confusion caused by differences in device manufacturers in real time and efficiently, and can intelligently fill in missing field values ​​at the millisecond level, avoiding device misjudgment caused by data interruption. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of a policy-driven intelligent device data processing method in one embodiment. Figure 2 This is a schematic diagram of device data reporting processing in a policy-driven intelligent device data processing method according to one embodiment. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0018] Example 1 like Figure 1 As shown in the figure, this embodiment proposes a policy-driven intelligent processing method for device data, the method comprising: S1: The device uploads a raw data packet, which includes a data item consisting of a device ID and multiple field names and field values; The specific implementation of this step is as follows: Receive the raw data packet uploaded by the device, which is a combination of device ID (device_id) and multiple attribute key-value pairs (key: value), where key represents the field name and value represents the field value.

[0019] S2: Query the device type based on the device ID, and obtain the bound child node policies in the policy tree based on the device type. The policy tree includes parent node policies and child node policies. The parent node policy is bound to the same device series to which multiple device types belong. Each parent node policy has multiple child node policies. The child node policies automatically inherit the parent node policies and support modification. The specific implementation of this step is as follows: Pre-enter basic device information (including device_id, type, mac, ip, address fields, etc.) and device type information (including type, strategy_id fields, etc.). Construct a tree-structured strategy tree containing a unique strategy identifier (strategy_id), a parent strategy identifier (parent_strategy_id), and JSON fields defining data processing rules. In the strategy tree, each device type is uniquely bound to a specific node (usually a leaf node) that defines the data processing rule set specific to that device type. Child node strategies automatically inherit all rules from the parent node strategy, and child node strategies can override rules based on inheritance.

[0020] Based on the device ID (device_id), query the pre-entered basic device information. After the query, obtain the corresponding pre-entered device type. Based on the device type, dynamically locate the uniquely bound policy node in the policy tree. Obtain the complete policy rule set (JSON format) that is exclusive to the device type and includes inheritance and overriding rules. To improve performance, cache the complete policy rule set (JSON format) corresponding to the device type. The caching component uses Redis, but is not limited to Redis.

[0021] S3: Process the data items using a child node strategy to obtain standardized field names, standardized field values, or temporary null values.

[0022] The specific implementation of this step is as follows: Field name standardization: Iterate through each attribute key in the original data message, and for each attribute key, perform an exact match with the FIELD rule module and its MATCH.ALIAS (field alias list) defined in the policy JSON rule of the currently effective child node. After a successful match, replace the original attribute key with the standardized field name of the FIELD rule module in the policy rule.

[0023] Field value processing: For each data item whose field name has been standardized (standard field name + original field value), if the field value exists in the original data message, the ACTIONS.ON_EXIST function defined in the FIELD rule of the child node policy is automatically called. This function performs preset data processing operations (e.g., unit conversion based on MATCH.UNIT_KEYWORDS convert_unit(), precision adjustment convert_accuracy(), and null value filling fill_default(), etc.). The processed value is used as the standardized output of the field; if the field value is missing (null value or no matching field name), the ACTIONS.ON_MISSING function defined in the FIELD rule of the child node policy is automatically called. In the initial state, this function usually performs basic operations (such as fill_null() to fill temporary null values), and filling temporary null values ​​avoids device misjudgment caused by data interruption.

[0024] Example 2 This embodiment further supplements the description of the strategy-driven intelligent processing method for device data proposed in the above embodiments.

[0025] The sub-node strategies include: FIELD rule module, MATCH rule module, ACTIONS rule module, and MODEL rule module; The FIELD rules module includes standardized field names; The MATCH rules module includes a list of field aliases and a list of unit keywords; The ACTIONS rules module includes functions for handling the presence of field values ​​and functions for handling the absence of field values; The MODEL rules module includes a list of feature extraction functions.

[0026] The specific implementation of this step is as follows: The JSON rule format defined in the child node strategy is as follows: FIELD: Standardized field; MATCH: -ALIAS: ["field alias 1", "field alias 2", "field alias 3"], -UNIT_KEYWORDS: ["Unit 1", "Unit 2"]; ACTIONS: -ON_EXIST: Library functions (built-in functions / custom functions / model functions), -ON_MISSING: Library functions (built-in functions / custom functions / model functions); MODEL: [Feature function, feature function, feature function].

[0027] The meanings of each attribute in the above JSON rule are as follows: FIELD: Defines a standardized target field name (e.g., "temperature"); MATCH: Includes ALIAS (a list of field aliases that specifies the list of aliases that the standardized field may appear in the raw data message (e.g., ["temp", "TEMP"])) and UNIT_KEYWORDS (a list of unit keywords that specifies the list of unit keywords that the field value may contain (e.g., ["℃"]), used to assist in identification and unit conversion), defining how to identify the field name corresponding to FIELD in the raw data message; ACTIONS: Defines the data processing behavior, including ON_EXIST (the processing function when the field value exists) and ON_MISSING (the processing function when the field value is missing). ON_MISSING can be associated with the MODEL field (specifying a list of feature extraction functions). ON_EXIST refers to the processing function for the field value when it exists (e.g., convert_unit("℃") performs unit conversion, and convert_accuracy(1) performs decimal precision processing). ON_MISSING refers to the processing function when the field value is missing (initially usually fill_null(), which represents filling temporary null values, and can be dynamically updated to the prediction function later). The MODEL field defines a list of feature extraction functions (e.g., [get_env_temp(), get_device_status()]) used for intelligent missing value completion. These functions are used to generate the feature vectors required by the model from the context (such as environmental data, other device statuses) when ON_MISSING needs to invoke the predictive model.

[0028] Library functions include, but are not limited to, built-in functions (null value handling, unit handling, precision handling, etc.), user-defined functions, value prediction model functions, and feature acquisition functions.

[0029] Child node policies automatically inherit parent node policies and can be modified, including: Rule modules whose child node policies are not defined inherit from the parent node policies; The rule modules defined by the child node strategy override the corresponding rule modules of the parent node strategy.

[0030] The specific implementation of this step is as follows: If a child node redefines any part of the MATCH, ACTIONS, or MODEL for the same FIELD, the child node's definition will completely override the rule part corresponding to that FIELD in the parent node; if a child node does not redefine the MATCH part (such as ALIAS or UNIT_KEYWORDS) of a FIELD in the parent node, the parent node's MATCH definition will be preserved and merged into the child node's final rule. An example is shown below: Parent node rule snippet: { "FIELD": "temperature", "MATCH": {"ALIAS": ["spindle_temp"], "UNIT_KEYWORDS": ["℃"]}, "ACTIONS": {"ON_EXIST": "convert_accuracy(1)", "ON_MISSING": "fill_null()"}; } Child node rule fragments (only overriding ACTIONS.ON_EXIST, adding MODEL, not overriding MATCH) { "FIELD": "temperature", "ACTIONS": { "ON_EXIST": "convert_unit('℃')&&convert_accuracy(1)", "ON_MISSING": "fill_null()"}, "MODEL": ["get_env_temp()", "get_load_current()"]; } Undefined rule portions of the child node policy (MATCH in this example) are directly inherited from the parent node policy; defined rule portions of the child node policy (ACTIONS.ON_EXIST and MODEL in this example) either override the corresponding portions of the parent node policy or are added as new items. The final effective rule for the device type bound to this child node policy is (merge the parent node's MATCH, override the parent node's ACTIONS.ON_EXIST, add MODEL, and retain the child node's ACTIONS.ON_MISSING): { "FIELD": "temperature", “MATCH”: {“ALIAS”: [“spindle_temp”], “UNIT_KEYWORDS”: [“℃”]}, / / Inherited from parent node "ACTIONS": { “ON_EXIST”: “convert_unit('℃')&&convert_accuracy(1)”, / / Overridden by child nodes “ON_MISSING”: “fill_null()” / / From child node }, “MODEL”: [“get_env_temp()”, “get_load_current()”]; / / From child node } Step S3 includes: S301: Use the FIELD rule module and the MATCH rule module to match the field names in the data items with the standardized field names. If the match is successful, the standardized field names are obtained. S302: Determine if a field value exists in the data item. If it exists, execute the field value existence processing function in the ACTIONS rule module to obtain the standardized field value. If it does not exist, execute the field value missing processing function in the ACTIONS rule module to obtain a temporary null value.

[0031] Step S301 also includes: If a match fails, the field names in the data item are processed according to predefined rules, which include: ignoring, logging, and default processing.

[0032] Step S302 also includes: Data is collected using the MODEL rules module to obtain feature data. The device type, standardized field names, feature data and timestamp are combined to form structured data and then written into the time series database. The feature data includes: ambient temperature features and device status features. Based on the aggregation and statistical capabilities of time-series databases, temporary null values ​​are statistically analyzed, and a missing rate index is generated in real time. If the missing rate index reaches the preset trigger condition, structured data is used as input to execute field value prediction model training, and a trained field value prediction model is obtained. The trained field value prediction model is encapsulated into a standardized function and the field value missing handling function is updated. Execute the missing field value handling function in the ACTIONS rules module to obtain the standardized field value and replace the temporary null value.

[0033] The specific implementation of this step is as follows: If the child node strategy JSON rule of this field defines MODEL (a list of feature functions), when the ON_MISSING function is called to supplement temporary null values, these feature functions (such as get_env_temp(), get_device_status()) will be executed synchronously to capture the current context environment features, collect device type, standardized field name, and feature values ​​(such as ambient temperature, device load current, etc.) calculated in real time by the feature functions in MODEL, and persist the above information to the time series database in a structured format [device type, standardized field name, feature value 1, feature value 2, ..., timestamp]. The feature values ​​are obtained by calling each feature function in the MODEL feature function list for the field during the standardization process of device reported data. The time series database includes, but is not limited to, IOTDB. Based on the aggregation and statistical capabilities of the time series database (supporting sliding window calculation and multi-dimensional grouping aggregation), the missing rate index (missing_rate=SUM(null_count) / SUM(total_count)*100%) of the <device type, standardized field name> dimension is generated in real time. null_count: The number of missing values ​​(Null) in a specific field for a specific device type within a specified time window. total_count: The total number of data points reported for a specific field value for a specific device type within a specified time window. missing_rate: The missing rate metric. These metrics accurately reflect the real-time data missing status of each field value under each device type.

[0034] Users can directly reference aggregate metrics from the time-series database on the management page (formatted as ${equipment type.normalized field name.missing rate metric}, example: ${CNC1000.temperature.missing_rate}, ${B.voltage.valid_count}) and configure conditional expressions. Supported expressions include: Threshold comparisons (e.g., >, <, >=, <=, ==); Logical operations (such as && (AND), || (OR), ! (NOT)); Time window continuity determination (continuous(N, condition), indicating that the condition is met for N consecutive statistical periods). Example: Continuous (3, ${A.temp.missing_rate}>10%), which means that the missing rate of the temperature field value of device type A is >10% for 3 consecutive statistical periods; ${B.voltage.missing_rate}>15%&&${B.voltage.valid_count}>=1000, meaning it is triggered when the voltage field value missing rate of device type B is >15% and the number of valid data is ≥1000.

[0035] When all logical evaluation results of any conditional expression are detected to be True, the model training task is immediately and automatically triggered. A task instruction (including device type and standardized field name) is sent to initiate the field value prediction model training task, accurately locating the structured data related to the target device type and target field stored in the time-series database. The corresponding model is selected for training based on numerical fields (such as temperature and voltage) or categorical fields (such as status codes). The trained model is dynamically encapsulated into an executable standardized function in the function operation library. This function takes as input a real-time context feature vector (generated in real-time by feature functions in the child node policy JSON rule MODEL rule module) and outputs the predicted value of the target field (continuous numerical value or discrete category).

[0036] The encapsulated function is registered in the function operation library, generating a standardized function handle (naming rule: predict_{device type}_{field name}_v{version number}, example: predict_CNC1000_temperature_v2). The policy tree is also updated synchronously and automatically. (1) Locate the child node strategy bound to this device type; (2) Modify the ON_MISSING operation of the corresponding field in the JSON rule of the child node strategy to call the newly registered function (e.g., update “ON_MISSING”: “fill_default()” to “ON_MISSING”: “predict_CNC1000_temperature_v2()”).

[0037] After the update is complete, the missing field value processing function in the ACTIONS rules module is executed to obtain the standardized field value and replace the temporary null value. Subsequently, when the missing field value is detected, the registered prediction function is automatically called, the real-time feature vector (device status, environmental parameters) is input, and the completed value is output to achieve millisecond-level high-precision intelligent filling.

[0038] The missing rate metric is displayed in the form of a heatmap.

[0039] The specific implementation of this step is as follows: The calculated dynamic missing rate matrix (dimension: device type × field name) is converted into a heat map visualization in real time. The heat map intuitively displays the missing rate of different device type-field name combinations with color gradients (e.g., green represents low missing rate, red represents high missing rate), providing operation and maintenance personnel with a real-time monitoring view of the overall data quality status.

[0040] The preset trigger conditions are written using aggregated metrics calculated in real time from a time-series database. These aggregated metrics include: device type, standardized field name, and missing rate metric.

[0041] Before training the field value prediction model, the process also includes selecting the field value prediction model based on the type of the field value to be predicted in the data item. If the field value to be predicted is numerical, the LightGBM regression model is selected; if the field value to be predicted is categorical, the XGBoost classification model is selected.

[0042] The specific implementation of this step is as follows: Numerical fields (such as temperature, voltage, and rotational speed) adopt the LightGBM regression model. The model uses the extracted related features (such as time series values ​​of other sensors and environmental variables) as input features (X) and the historical valid values ​​of the target field as the regression target (Y) to learn the predictive mapping relationship of continuous numerical values. Categorical fields (such as device status codes and alarm codes) employ the XGBoost classification model. This model uses techniques such as feature cross-coding to learn the distribution patterns of discrete category values. The input feature (X) is also a correlation feature, and the classification target (Y) consists of the historical valid discrete values ​​of the target field.

[0043] The field value prediction model is trained using an incremental learning mode.

[0044] The specific implementation of this step is as follows: Retrieve the model state (including model parameters and architecture) of the most recently successfully trained target field value. Use this state as the initial weights and foundation, and only load the newly added data corresponding to this task (data after the last training) for iterative optimization. This significantly reduces training resource consumption, accelerates convergence, and ensures that model knowledge continues to evolve with new data. Strict model version management is implemented. After each successful training, a unique model version number (e.g., model_v3) is generated, and the data version number (e.g., data_version=20240720, identifying the training data range) is recorded. Version information is stored in association with model parameters and performance evaluation metrics to ensure full traceability of the model's lifecycle and version backtracking.

[0045] Example 3 like Figure 2 As shown, the system built based on the policy-driven intelligent processing method for device data includes: Device policy configuration module: Provides centralized management of key device attributes and policy rules, enabling unified operation of device information and policy inheritance configuration. Specifically, it includes: device information management, policy management, and device type and policy binding management; Field matching engine: Performs data normalization transformation based on policy nodes bound to device type; Heatmap Decision Engine: Calculates the missing frequency matrix of device type and field dimension in real time, generates dynamic heatmaps, and automatically triggers model training tasks when the missing rate exceeds the threshold; Virtual prediction engine: Loads training data online and performs incremental model training and real-time missing value inference based on device type / field dimension; Model data acquisition module: Data collection is performed by embedding data points in the data standardization process, and the feature dataset required for training the prediction model is collected according to the defined strategy. Function operation library: Provides pluggable function instances (data transformation / de-identification / model calling, etc.).

[0046] A car parts factory's 200 CNC machine tools (models CNC1000 / CNC2000) frequently experience missing temperature sensor data during processing (due to poor contact caused by high-temperature vibration). Traditional manual data compensation has an error rate of ±5℃, affecting the yield rate.

[0047] After using this system, engineers construct a three-layer dynamic policy tree using the device policy configuration module. The root is a general device node, which declares the standard field "temperature" in concise JSON, while also including common aliases such as "temp" and "TEMP," as well as unit symbols "℃" and "°C." Machine tool nodes (parent node policies) inherit the general rules, only using "fill_null()" as a placeholder when missing values. Further down, the CNC1000 child node policies further supplement two feature functions—"get_env_temp()" and "get_load_current()"—to prepare two key inputs for the subsequent model: ambient temperature and load current. In this way, newly added CNC2000 nodes only need to be attached to the same parent node policy, without needing to rewrite the entire set of rules; policy inheritance completes most of the work.

[0048] Once the device is powered on, the data stream flows into the field matching engine via MQTT. CNC#001 sends a message: {device_id: "CNC#001", spindle_temp: 85.3, load_current: 120A}. The field matching engine finds the CNC1000 type based on the device_id, then locates the leaf node strategy, and instantly completes the field name standardization—spindle_temp becomes temperature; subsequently, convert_unit('℃') and convert_accuracy(1) are executed successively to ensure that the unit is consistent and the precision is retained to one decimal place. If a message is missing a temperature field value, fill_null() is called to temporarily fill the value to ensure the continuity of the data stream. At the same time, real-time features are extracted: get_env_temp()→28℃, get_load_current()→118A. The real-time temperature of 28℃ and the real-time current of 118A in the workshop are collected and written to the time series database along with the timestamp. The data is persistently stored in a structured format [equipment type, field name, feature value 1, feature value 2, timestamp] as training data for subsequent models.

[0049] The thermal decision engine slides a window every five minutes to calculate the missing rate of CNC1000.temperature. If the proportion of missing values ​​to total reports exceeds 12% for three consecutive times in the past twenty minutes, once the trigger condition is met, the thermal decision engine sends a lightweight instruction to the virtual prediction engine, which simply states "Start a new round of model training for the temperature field of CNC1000". After receiving the instruction, the virtual prediction engine obtains all CNC1000-temperature records accumulated in the time series database from the model data acquisition module. These records contain both standardized real temperature values ​​and features such as ambient temperature, load current, and continuous running time written by the field matching engine at the same time, which together constitute the dataset required for training. LightGBM starts in incremental mode, first loading the parameters of the old model predict_CNC1000_temperature_v1, then fine-tuning it with two thousand new data points. A few minutes later, after incremental training, the new model predict_CNC1000_temperature_v2 achieves a validation set determination coefficient of 0.92 and a mean absolute error (MAE) of 0.8℃. The virtual prediction engine immediately registers it as a callable function in the function operation library and replaces the ON_MISSING function of the CNC1000 node in the policy tree from fill_null() to predict_CNC1000_temperature_v2(), all without manual intervention. The next time CNC1000 misses a temperature report, but the message still contains load_current: 125A and env_temp: 30℃, the field matching engine directly calls predict_CNC1000_temperature_v2(30, 125), returning 89.6℃ within milliseconds, accurately filling the missing value. The heat map on the workshop's large screen also updated accordingly: the square representing CNC1000.temperature changed from red to green, indicating to maintenance personnel that the temperature data of this production line had returned to a healthy range.

Claims

1. A strategy-driven intelligent processing method for device data, characterized in that, include: S1: The device uploads a raw data packet, which includes a data item consisting of a device ID and multiple field names and field values; S2: Query the device type based on the device ID, and obtain the bound child node policies in the policy tree based on the device type. The policy tree includes parent node policies and child node policies. The parent node policy is bound to the same device series to which multiple device types belong. Each parent node policy has multiple child node policies. The child node policies automatically inherit the parent node policies and support modification. S3: Process the data items using a child node strategy to obtain standardized field names, standardized field values, or temporary null values.

2. The strategy-driven intelligent processing method for device data according to claim 1, characterized in that, The sub-node strategies include: FIELD rule module, MATCH rule module, ACTIONS rule module, and MODEL rule module; The FIELD rules module includes standardized field names; The MATCH rules module includes a list of field aliases and a list of unit keywords; The ACTIONS rules module includes functions for handling the presence of field values ​​and functions for handling the absence of field values; The MODEL rules module includes a list of feature extraction functions.

3. The strategy-driven intelligent processing method for device data according to claim 2, characterized in that, Child node policies automatically inherit parent node policies and can be modified, including: Rule modules whose child node policies are not defined inherit from the parent node policies; The rule modules defined by the child node strategy override the corresponding rule modules of the parent node strategy.

4. The strategy-driven intelligent processing method for device data according to claim 2, characterized in that, Step S3 includes: S301: Use the FIELD rule module and the MATCH rule module to match the field names in the data items with the standardized field names. If the match is successful, the standardized field names are obtained. S302: Determine if a field value exists in the data item. If it exists, execute the field value existence processing function in the ACTIONS rule module to obtain the standardized field value. If it does not exist, execute the field value missing processing function in the ACTIONS rule module to obtain a temporary null value.

5. The strategy-driven intelligent processing method for device data according to claim 4, characterized in that, Step S301 also includes: If a match fails, the field names in the data item are processed according to predefined rules, which include: ignoring, logging, and default processing.

6. The strategy-driven intelligent processing method for device data according to claim 4, characterized in that, Step S302 also includes: Data is collected using the MODEL rules module to obtain feature data. The device type, standardized field names, feature data and timestamp are combined to form structured data and then written into the time series database. The feature data includes: ambient temperature features and device status features. Based on the aggregation and statistical capabilities of time-series databases, temporary null values ​​are statistically analyzed, and a missing rate index is generated in real time. If the missing rate index reaches the preset trigger condition, structured data is used as input to execute field value prediction model training, and a trained field value prediction model is obtained. The trained field value prediction model is encapsulated into a standardized function and the field value missing handling function is updated. Execute the missing field value handling function in the ACTIONS rules module to obtain the standardized field value and replace the temporary null value.

7. The strategy-driven intelligent processing method for device data according to claim 6, characterized in that, The missing rate metric is displayed in the form of a heatmap.

8. The strategy-driven intelligent processing method for device data according to claim 6, characterized in that, The preset trigger conditions are written using aggregated metrics calculated in real time from a time-series database. These aggregated metrics include: device type, standardized field name, and missing rate metric.

9. The strategy-driven intelligent processing method for device data according to claim 6, characterized in that, Before training the field value prediction model, the process also includes selecting the field value prediction model based on the type of the field value to be predicted in the data item. If the field value to be predicted is numerical, the LightGBM regression model is selected; if the field value to be predicted is categorical, the XGBoost classification model is selected.

10. The strategy-driven intelligent processing method for device data according to claim 6, characterized in that, The field value prediction model is trained using an incremental learning mode.

Images