Configurable artificial intelligence application system and method for industrial automation

Abstract

The invention provides a configurable artificial intelligence application system and method for industrial automation. Comprising a visual configuration module used for performing consistency verification and versioning storage on a configuration graph to form a configuration snapshot; the algorithm library module is used for being selected and instantiated into algorithm nodes according to the configuration graph; the data processing module is used for generating a data processing snapshot associated with the configuration snapshot; the training engine module is used for receiving the parameter adjustment instruction from the visual configuration module, updating adjustable parameters in a training process, recording associated information of the parameters, data and a model according to training rounds, and exporting a model package; and the inference engine module is used for loading the model package and the associated data processing snapshot, performing parameterized configuration on multi-source data access according to the configuration graph, and executing online inference to generate an inference result. According to the method, configurable integration of an algorithm and a data flow can be realized, a training deployment threshold is reduced, and consistency and traceability of training and reasoning are guaranteed.

Description

Technical Field

[0001] This application relates to the field of industrial automation software technology, and in particular to a configurable artificial intelligence application system and method for industrial automation. Background Technology

[0002] The rapid evolution of industrial automation towards intelligentization presents a growing demand for scalable, low-latency, and traceable artificial intelligence from massive amounts of sensor data and diverse business scenarios. Existing industrial software often introduces AI through built-in fixed algorithm libraries or external model services, with a few platforms offering templated or low-code capabilities. Training and deployment typically require developers to manually orchestrate data cleaning, feature engineering, and inference processes, making it difficult to seamlessly integrate with on-site industrial protocols, edge computing environments, and real-time monitoring systems.

[0003] The existing technology still has the following shortcomings: First, the integration of fixed algorithms lacks universality, making it difficult to select algorithms and adjust parameters according to differentiated needs such as quality inspection, fault diagnosis, and predictive maintenance; second, training and deployment are highly dependent on coding and parameter tuning capabilities, making it difficult for non-professionals to independently complete the end-to-end process; third, the preprocessing process for multi-source heterogeneous data lacks a configurable mechanism, and the data processing chain and model chain lack consistent versioning and traceability; fourth, the model version management, gray-scale switching, and rollback capabilities are weak, and the lightweight deployment at the edge and the adaptation to multi-source real-time access are insufficient. Summary of the Invention

[0004] In view of this, embodiments of this application provide a configurable artificial intelligence application system and method for industrial automation, in order to solve the problems of existing technologies, such as the difficulty in configurably integrating algorithms and data processing according to scenarios, the high threshold for training and deployment by non-professionals, and the lack of consistency and traceability of training and inference links based on unified data processing snapshots.

[0005] The first aspect of this application provides a configurable artificial intelligence application system for industrial automation, comprising: a visualization configuration module for providing graphical orchestration operations and generating configuration diagrams, performing consistency verification and versioned storage on the configuration diagrams to form configuration snapshots, wherein the configuration diagrams include nodes, connections, and parameter information; an algorithm library module for providing algorithm entries with a unified calling interface, which are selected and instantiated as algorithm nodes according to the configuration diagrams, wherein the algorithm entries carry the required data processing flow templates and parameter templates; a data processing module for performing data cleaning, normalization, and feature extraction according to the configuration diagrams, generating data processing snapshots associated with the configuration snapshots; a training engine module for assembling training flows according to the configuration diagrams and data processing snapshots, receiving parameter adjustment instructions from the visualization configuration module, updating adjustable parameters during the training process, recording the association information of parameters, data, and models according to training rounds, and exporting model packages; and an inference engine module for loading model packages and associated data processing snapshots, parameterizing the access of multi-source data according to the configuration diagrams, and performing online inference to generate inference results.

[0006] The second aspect of this application provides a configurable artificial intelligence application method for industrial automation based on the system of the first aspect, comprising: graphical arrangement in a visualization configuration module to generate a configuration diagram containing node, connection and parameter information; performing consistency verification on the configuration diagram and storing it in a versioned manner to form a configuration snapshot; selecting algorithm entries from the algorithm library module according to the configuration diagram, generating an instantiated parameter set according to the parameter template and creating algorithm nodes; having the data processing module parse the configuration diagram to determine the sequence of data processing operators, receiving industrial data and sequentially performing data cleaning, normalization and feature extraction to generate a data processing snapshot associated with the configuration snapshot; having the training engine module assemble the training process based on the configuration diagram and the data processing snapshot, loading the algorithm nodes and initializing the training parameters, updating the adjustable parameters online according to the parameter adjustment instructions, recording the association information of parameters, data and model according to the training rounds and exporting the model package; having the inference engine module load the model package and the associated data processing snapshot, parameterizing the access of multi-source data according to the configuration diagram, performing preprocessing on the accessed data according to the data processing snapshot, and calling the algorithm nodes to perform online inference to generate inference results.

[0007] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: The application employs a visual configuration module to provide graphical orchestration operations and generate configuration diagrams. These diagrams undergo consistency verification and versioning to create configuration snapshots, each containing node, connection, and parameter information. An algorithm library module provides algorithm entries with a unified calling interface. These entries are selected and instantiated as algorithm nodes based on the configuration diagram, each carrying the required data processing flow template and parameter template. A data processing module performs data cleaning, normalization, and feature extraction based on the configuration diagram, generating a data processing snapshot associated with the configuration snapshot. A training engine module assembles the training flow based on the configuration diagram and data processing snapshot. It receives parameter adjustment instructions from the visual configuration module, updates adjustable parameters during training, records the association information between parameters, data, and the model according to training rounds, and exports the model package. An inference engine module loads the model package and associated data processing snapshot, performs parameterized configuration for multi-source data access based on the configuration diagram, and performs online inference to generate inference results. This application enables configurable integration of algorithms and data flows, lowers the training deployment threshold, and ensures consistent traceability between training and inference. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a schematic diagram of the structural composition of a configurable artificial intelligence application system for industrial automation provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a configurable artificial intelligence application method for industrial automation provided in an embodiment of this application. Detailed Implementation

[0010] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0011] With the continuous development of industrial automation, the application of artificial intelligence (AI) technology is becoming increasingly widespread. However, existing industrial automation software faces numerous challenges when integrating and applying AI algorithms. On the one hand, different industrial scenarios have varying requirements for AI algorithms, and traditional fixed algorithm integration methods are insufficient to meet these diverse needs. On the other hand, for non-AI professionals, training and deploying AI models is complex and difficult, lacking a simple and efficient way to customize AI applications according to specific industrial needs. Furthermore, in terms of data processing and analysis workflows, a more flexible and configurable mechanism is needed to adapt to the characteristics and processing requirements of different industrial data.

[0012] The purpose of this application is to address the following three core issues in the application of artificial intelligence in industrial automation software.

[0013] First, traditional fixed algorithm integration is difficult to adapt to diverse needs. Different industrial scenarios (such as quality inspection, fault diagnosis, and equipment prediction) have significantly different requirements for AI algorithms. Existing software mostly adopts a fixed algorithm integration mode, which cannot flexibly respond to the needs of algorithm selection and parameter adjustment in different scenarios, resulting in insufficient versatility.

[0014] Secondly, the high barrier to entry for non-professionals. Operators in the industrial sector often lack AI expertise, and the training and deployment processes of existing AI models involve complex code writing and parameter debugging, which are difficult for non-professionals to master, thus limiting the widespread application of AI technology in industrial automation.

[0015] Finally, the data processing workflow lacks a flexible configuration mechanism. Industrial data is diverse (such as sensor time-series data, image data, production logs, etc.), and its preprocessing requirements (such as noise reduction, feature extraction, format conversion, etc.) vary from scenario to scenario. Existing software data processing workflows are mostly fixed patterns and cannot be flexibly configured according to data characteristics, which affects the performance and applicability of subsequent AI models.

[0016] In view of the problems existing in the prior art, this application provides a configurable AI application framework. The basic content of the configurable AI application framework of this application is briefly described below: I. System Architecture The configurable AI application framework mainly includes the following core components: Visual configuration interface: Provides an intuitive graphical user interface, allowing users to select artificial intelligence algorithms, build data processing workflows, and configure training and inference processes by dragging and dropping, and setting parameters. For example, users can select suitable classification algorithms (such as support vector machines, neural networks, etc.) from the algorithm library, drag them to the workspace, and configure key parameters of the algorithm, such as the number of layers and nodes in the neural network, through the property settings window.

[0017] AI Algorithm Library: This library integrates a rich collection of artificial intelligence algorithms, covering multiple fields such as machine learning and deep learning. The algorithms in the library are encapsulated with a unified interface for easy user access during configuration. For example, the machine learning algorithm library includes classic algorithms such as decision trees and Naive Bayes; the deep learning algorithm library includes commonly used models such as convolutional neural networks and recurrent neural networks.

[0018] Data processing module: Supports various preprocessing operations on industrial data, such as data cleaning, normalization, and feature extraction. Users can configure the data processing workflow in a visual interface and select appropriate processing steps based on the data characteristics. For example, for noisy data collected by sensors, a data cleaning algorithm can be selected first to remove outliers, followed by normalization processing to improve the performance of subsequent algorithms.

[0019] Training Engine: This engine trains the data based on user-configured training parameters and selected algorithms. During training, it provides real-time feedback on training progress and performance metrics (such as accuracy and loss value), which users can view in a visual interface. For example, when training a neural network model, the training engine will train according to set parameters such as the number of iterations and learning rate, and display the accuracy and loss value of each training round in real-time on the visual interface, allowing users to easily adjust training parameters.

[0020] Inference Engine: The trained model is deployed to the inference engine to perform inference and prediction on real-time data. The inference results can be fed back to the industrial control system in real time, enabling intelligent control decisions. For example, in an industrial fault diagnosis scenario, the inference engine uses a trained fault diagnosis model to infer from real-time collected equipment operating data, determine whether the equipment has a fault, and promptly feed back the diagnosis results to the operators.

[0021] II. Configuration Process Data Processing Workflow Configuration: Based on the characteristics of industrial data and the needs of the algorithm, users can build data processing workflows in a visual interface. For example, for industrial sensor data containing a large amount of noise, users can sequentially select data cleaning, filtering, feature extraction, and other data processing steps, and set the parameters for each step. The data processing module will process the data according to the user-configured workflow, providing high-quality data for subsequent training and inference.

[0022] Algorithm Configuration: In the visual configuration interface, users select the desired artificial intelligence algorithm from the AI ​​algorithm library. For example, in an industrial quality inspection scenario, users choose a convolutional neural network algorithm for image recognition based on the characteristics of the inspection task. Then, by setting the algorithm's parameters, such as network structure and training hyperparameters, the algorithm configuration is completed.

[0023] Training and Inference Configuration: Users set relevant training parameters, such as training dataset, validation dataset, number of training epochs, and learning rate. The training engine trains the selected algorithm based on these parameters. After training, users can deploy the trained model to the inference engine and set relevant inference parameters, such as the input data format and output result processing method. The inference engine performs inference on real-time data based on the set parameters and feeds the inference results back to the user or industrial control system.

[0024] III. Visual Display This framework provides rich visualization features, allowing users to easily understand the effects of training and inference in real time.

[0025] Training process visualization: During training, the visualization interface displays real-time curves showing changes in metrics such as training progress, accuracy, and loss value. Users can intuitively understand the training progress through these curves, determine whether the model has converged, and whether training parameters need adjustment. For example, if the accuracy curve fluctuates or stagnates during training, users can try adjusting parameters such as the learning rate and retraining.

[0026] Visualization of Inference Results: The results output by the inference engine are displayed in an intuitive way on the visualization interface. For example, in industrial equipment condition monitoring scenarios, inference results can use icons of different colors to represent the normal, warning, and fault states of the equipment; in industrial production quality inspection scenarios, inference results can use image annotations to show the location and type of detected defects.

[0027] The specific modules and functions of the configurable artificial intelligence application system for industrial automation provided in this application will be described in detail below with reference to the accompanying drawings and specific embodiments. Figure 1 This is a schematic diagram of the structural composition of a configurable artificial intelligence application system for industrial automation provided in an embodiment of this application, such as... Figure 1 As shown, this configurable artificial intelligence application system for industrial automation may specifically include the following modules: The visualization configuration module 101 is used to provide graphical arrangement operations and generate configuration diagrams, perform consistency verification and version storage on the configuration diagrams to form configuration snapshots, wherein the configuration diagrams contain node, connection and parameter information; Algorithm library module 102 is used to provide algorithm entries with a unified calling interface, and is selected and instantiated as algorithm nodes according to the configuration diagram. The algorithm entries carry the required data processing flow template and parameter template. Data processing module 103 is used to perform data cleaning, normalization and feature extraction based on the configuration diagram, and generate a data processing snapshot associated with the configuration snapshot; The training engine module 104 is used to assemble the training process according to the configuration diagram and data processing snapshot, receive parameter adjustment instructions from the visualization configuration module, update the adjustable parameters during the training process, record the correlation information between parameters, data and model according to the training rounds, and export the model package. The inference engine module 105 is used to load the model package and associated data processing snapshots, perform parameterized configuration of multi-source data access according to the configuration diagram, and execute online inference to generate inference results.

[0028] It should be noted that the visual configuration interface provided in this application is used to graphically display data processing nodes, algorithm nodes, and their connection relationships. Users complete the configuration of the AI ​​application process by dragging and dropping components, drawing connections, and filling in parameters. After the user completes the configuration, the system automatically converts the above graphical configuration into internally parsable configuration data. The configuration data includes structured information such as node types, connection relationships between nodes, parameters of each node, and dependencies. This application refers to the structured configuration data generated by the visual configuration interface and called by the backend module as a "configuration diagram." The training engine module, inference engine module, and related functional modules can all assemble and execute processes based on this configuration diagram.

[0029] In some embodiments, a graphical orchestration operation is provided to generate a configuration diagram, and the configuration diagram is subjected to consistency verification and versioned storage to form a configuration snapshot, including: It receives node drags, connections, and parameter inputs from users in the visual interface, and solidifies the node types, connection relationships, and parameter sets into a configuration diagram. Based on the parameter templates and data processing flow templates carried by the algorithm entries in the algorithm library module, generate a description of the parameter constraints and dependencies between the algorithm nodes and data processing nodes in the configuration diagram; Perform consistency checks on the configuration diagram. The consistency checks include matching checks of node types and connection directions, matching checks of data formats and sampling characteristics, legality checks of required parameters and their value ranges, and integrity checks of upstream and downstream dependencies. The verified configuration diagrams are stored in a versioned manner, and corresponding configuration snapshot identifiers are generated. The association information with the algorithm entry version and the data processing flow template version is recorded to form a configuration snapshot.

[0030] Specifically, the visualization configuration module in this embodiment is used to provide graphical orchestration operations to generate configuration configuration data including node, connection and parameter information, convert the configuration configuration data into a configuration diagram, and perform consistency verification and versioned storage on the configuration diagram to form a configuration snapshot.

[0031] In the visual configuration module, users drag and drop nodes, connect lines, and input parameters via a canvas. The system embeds these interactions into a configuration diagram, which includes a node set, a connection set, and a parameter set. Nodes, categorized by function, include at least data processing nodes and algorithm nodes; each node records its identifier, node type, input / output port description, and parameter entries. Connections record source ports, target ports, and data format constraints. The parameter set includes key names, data types, value ranges, required fields, default values, and units. The configuration diagram serves as input for subsequent consistency checks and versioned storage.

[0032] The visualization configuration module requests parameter templates and data processing flow templates corresponding to the algorithm entries from the algorithm library module. The parameter templates define the configurable parameter entries for algorithm nodes and their validation rules; the data processing flow templates indicate the algorithm's prerequisites for the upstream data processing chain, including at least the expected data format (e.g., time-series batch length, feature dimension, sampling rate) and recommended operator sequences (e.g., missing value handling → normalization → feature extraction / serialization). The system compiles the above template content into a "constraint and dependency description" within the configuration diagram, specifically including: annotations of required parameters and value ranges for algorithm nodes, existence and order constraints for upstream data processing nodes, and matching constraints for port types between nodes, establishing reference relationships using template version numbers.

[0033] In some examples, consistency checks are triggered before committing the store and include at least the following checks: Node type and connection direction matching verification: Verify that the connection is established only between the output port and the input port, and that the output of the data processing node can be received by the input port of the algorithm node.

[0034] Data format and sampling characteristic matching verification: verify that the data format at both ends of the connection is consistent or can be adapted through declared transformation; verify that the sampling rate, window length, stride, feature dimension are consistent with the expected input of the algorithm node.

[0035] Parameter validity verification: Verify each required field, type, numerical range, and unit according to the parameter template rules.

[0036] Upstream and downstream dependency integrity verification: Verify whether the pre-operators declared in the data processing flow template exist in the graph and meet the order requirements; verify that all necessary input ports of the algorithm node are connected.

[0037] Structural robustness verification (optional): loop detection, unused node detection, duplicate identifier detection.

[0038] Once all verifications pass, a verification report is generated and versioned storage is allowed; if any item fails, the report lists the specific failure item, node identifier, and rectification suggestions, thus blocking the storage process.

[0039] In some examples, the system calculates a structured summary of the validated configuration diagram and assigns a configuration snapshot identifier. The recorded content includes: a configuration diagram structure summary, a list of nodes and connections, a parameter set, a timestamp, the submitter, a description, and association information with the algorithm entry version, parameter template version, and data processing flow template version. An immutable snapshot strategy is used for storage; once a snapshot is generated, it is not overwritten. Subsequent modifications to the same project will generate new snapshot identifiers. The system maintains a snapshot index, supporting retrieval by project identifier and time sequence for subsequent reference by the training and inference engines.

[0040] In some examples, the implementation details of the interface interaction to the configuration diagram include the following: Node drag and drop: When a user drags “Data Cleaning”, “Normalization”, “Feature Extraction”, “Algorithm Node”, etc. from the component panel to the canvas, the system assigns a unique node identifier to each node and loads the parameter form template corresponding to that node type.

[0041] Connection establishment: When a user establishes a connection from the output port of an upstream node to the input port of a downstream node, the system immediately verifies the compatibility of the port type and data format, and writes the format description and sampling attributes into the connection object.

[0042] Parameter input: The parameter form provides numerical input, range limits and enumeration selection. The system performs front-end and back-end dual validation of the required fields and value ranges based on the parameter template, and solidifies the final parameter set into the corresponding node in the configuration diagram.

[0043] Configuration diagram generation: After completing the above operations, the system constructs a configuration diagram object with a set of nodes, a set of connections, and a set of parameters, and fills in the necessary version and reference metadata for consumption by the consistency verification module.

[0044] For example, taking equipment failure prediction as an example, users sequentially arrange nodes on the canvas: a data cleaning node (including outlier handling methods), a normalization node (including standardization strategies), a feature extraction node (including time-series sliding window size and stride), and an algorithm node (selecting the algorithm entry for time-series prediction and filling in the hidden layer size, learning rate, and number of training epochs). The parameter template returned by the algorithm library limits the adjustable range and required fields, and the data processing flow template indicates that the upstream must include the sequence of "cleaning → normalization → serialization / feature extraction". The system matches and verifies the sampling rate and window length of the connections, checks the expected input dimension of the algorithm nodes, and generates a configuration snapshot identifier after verification, recording the algorithm entry version and the corresponding template version number. This configuration snapshot identifier serves as a reference entry in the subsequent training and inference phases, ensuring that the same data processing chain is consistently loaded.

[0045] When an upgrade to the template version of the algorithm library module results in changes to parameter items, the system triggers a "template migration check" during the configuration diagram saving phase. This prompts for newly added required fields or changes in value ranges and generates migration suggestions. If the user confirms the migration, the system completes or corrects the parameter set based on the new template, re-executes the consistency check, and generates a new snapshot. If the user refuses the migration, the system maintains the original snapshot and prevents inconsistent combinations with the new template. No snapshot identifier is generated for any failed checks, thus preventing subsequent training and inference from referencing inconsistent configurations.

[0046] When the training engine and inference engine are integrated into this embodiment, they retrieve the configuration diagram structure and template reference information by configuration snapshot identifier. They then pull the configuration diagram and versioned dependencies from the configuration storage by identifier, ensuring consistency in the order of nodes loaded, parameter sets, and data format descriptions during the training and inference phases. The visualization configuration module provides a snapshot query interface, supporting retrieval by project and time dimensions, export and archiving by identifier, to meet the traceability loading requirements of subsequent processes.

[0047] Through the above embodiments, a complete implementation process was completed, from graphical orchestration to configuration diagram solidification, from template-driven parameter and dependency generation to consistency verification, and then to immutable versioned storage and the formation of configuration snapshots. The specific association method with industrial equipment fault prediction scenarios is also given, so that subsequent training and inference stages can be consistently referenced and executed based on the configuration snapshot.

[0048] In some embodiments, algorithm entries with a unified calling interface are provided and selected and instantiated as algorithm nodes according to the configuration diagram, including: It provides algorithm entry metadata and a unified calling interface, which is used to perform training, inference and evaluation. Based on the selection of algorithm nodes and parameter configuration in the configuration diagram, the corresponding algorithm entries are loaded from the algorithm library module, and an instantiated parameter set is generated by combining the parameter template, and a reference relationship is established with the data processing flow template indication; Perform consistency checks on the algorithm nodes before instantiation, and create algorithm node instances after the checks pass, registering the association information between the algorithm node identifier and the algorithm entry version, parameter template version, and data processing flow template version.

[0049] Specifically, in the algorithm library module, metadata and a unified calling interface are established for each algorithm entry. The metadata records at least: algorithm name, applicable task type, expected input data format, required and optional parameter set, parameter value range and unit, default parameters, required data processing workflow template, supported evaluation metric set, and version number. The unified calling interface serves as the entry point for training, inference, and evaluation. The interface's input and output parameters use the same internal data representation as the data processing module's output. This internal data representation includes data format, time stamp, and channel identifier, ensuring stable integration between the algorithm entry and the upstream data processing snapshot. To ensure consistency with actual engineering, the algorithm entry also registers the random number seed strategy, weight storage format, and dependent library version identifier, enabling integrated referencing when the training engine module exports the model package.

[0050] Furthermore, after the visualization configuration module generates and submits a configuration diagram containing algorithm nodes, the system parses the algorithm node identifier, node type, and parameter input set in the configuration diagram. Based on this, the algorithm library module locates the target algorithm entry and loads its parameter template and data processing flow template indication. The system aligns the parameter template with the parameters entered by the user in the configuration interface, completes the default values, and verifies the value range to form an instantiated parameter set. Simultaneously, the data processing flow template indication carried by the algorithm entry is written into the constraint domain of the configuration diagram to indicate or enforce the existence of upstream pre-operators such as cleaning, normalization, feature extraction, or serialization. The instantiated parameter set and template version number are bound to the attribute domain of the algorithm node to ensure that subsequent training and inference phases can run based on the same parameter view.

[0051] Furthermore, before creating an algorithm node instance, the system triggers a consistency check, covering at least the following aspects: First, input form verification, matching the input dimensions, sampling characteristics, and batch processing strategies declared in the algorithm entry's metadata with the output form of the data processing node in the current configuration diagram; Second, parameter validity verification, checking each required field, data type, upper and lower limits of value, and unit according to parameter template constraints; Third, dependency integrity verification, verifying whether the pre-operators indicated by the data processing flow template exist in the configuration diagram and whether the connection order meets the requirements; Fourth, matching verification with the training engine module interface, ensuring that the training entry signature of the algorithm entry is consistent with the training engine assembly process. For entries that fail the verification, the system returns the specific inconsistent entry, node identifier, and rectification suggestions, rejecting instantiation; for entries that pass the verification, instance creation proceeds.

[0052] Furthermore, after successful verification, the system generates algorithm node instances and assigns node identifiers. Each instance includes: algorithm entry version number, parameter template version number, data processing flow template version number, instantiated parameter set summary, input data format summary, and a set of allowed evaluation metrics. The algorithm node instance establishes a reference relationship with its corresponding configuration snapshot and writes it to the graph storage of the visualization configuration module. To ensure traceable loading in subsequent stages, the system also registers the mapping relationship between algorithm node instances and algorithm entry versions in the configuration storage and provides a query interface for the training engine module and inference engine module to read by node identifier.

[0053] For example, taking fault prediction as an example, the user arranges the chain of "data cleaning → normalization → feature extraction → algorithm node" on the canvas. The algorithm node selects the target algorithm for time series modeling, and the configuration parameters specify the hidden layer size, learning rate, number of training epochs, batch size, etc. The algorithm library module returns the parameter template and data processing flow template instructions for the algorithm entry, requiring that the upstream must have outlier handling, standardization, and sliding window feature construction. The system matches and verifies the window length and stride of the connection with the upstream output dimension, and verifies the required fields and ranges in the parameter template.

[0054] After all verifications pass, the system creates algorithm node instances, assigns node identifiers, and writes the instantiated parameter set, algorithm entry version, parameter template version, and data processing flow template version into the graph storage, while establishing a reference relationship with the configuration snapshot. Subsequently, the training engine module assembles the training flow and outputs the model package accordingly; the inference engine module loads the corresponding algorithm implementation according to the node identifier during deployment, and synchronously loads the data processing snapshot associated with the model package to ensure consistency with the input format during the training phase.

[0055] When algorithm library modules upgrade algorithm entries or parameter templates, resulting in changes to parameter items, the system triggers template migration verification when reading the old instantiated parameter set. This prompts for newly added required fields or range changes. One-click migration to generate a new version instance is supported, as is maintaining the existing version to preserve the availability of historical snapshots. Any verification failure due to incomplete migration will prevent the generation of new instances, avoiding inconsistent configurations during training or inference.

[0056] Through the above embodiments, the system achieves a unified calling interface and standardized metadata management at the algorithm item level. Combined with the configuration diagram, it completes the selection of algorithm nodes, parameter instantiation, consistency verification and version registration, enabling the training engine module and the inference engine module to be assembled and executed based on the same algorithm instance and data processing constraints, thereby improving the consistency, reusability and traceability of algorithm integration.

[0057] In some embodiments, data cleaning, normalization, and feature extraction are performed based on the configuration diagram to generate a data processing snapshot associated with the configuration snapshot, including: Analyze the data processing nodes and directed connections in the configuration diagram to determine the operator sequence and parameter set used for data processing, and establish a reference relationship with the configuration snapshot; The input from industrial data sources is acquired and unified into an internal data representation, which includes data format, time stamp, and channel stamp. Data cleaning, normalization, and feature extraction are performed sequentially according to the operator sequence, and the consistency between the data form of each operator input and output and the input expectation of the algorithm node is verified during the execution process. Data processing snapshots are generated based on operator sequences, parameter sets, data form mapping relationships, and association information with configuration snapshots and algorithm nodes.

[0058] Specifically, in the configuration diagram generated by the visualization configuration module, data processing-related nodes include data cleaning nodes, normalization nodes, and feature extraction nodes, which form a processing link through directed connections. The system first parses the node types, input / output ports, and connection order to determine the operator sequence as "cleaning → normalization → feature extraction," and collects the parameter sets for each node, such as the outlier strategy and threshold for the cleaning node, the normalization method for the normalization node, and the sliding window length and stride for the feature extraction node. After parsing, a reference relationship is established between the operator sequence and parameter set and the configuration snapshot, and the configuration snapshot identifier is recorded to ensure subsequent traceability.

[0059] Furthermore, the data processing module obtains input from industrial data sources, which can be MQTT-based sensor channels, OPC-based device variables, historical tables in a database, or aggregated streams from an HTTP interface. To shield against upstream differences, the system unifies the raw data into an internal data representation, which includes at least the data format (identified as time series or image and describing dimensions), time identifier (timestamp or sampling sequence number), and channel identifier (sensor number or variable name). In fault prediction scenarios, vibration, temperature, and pressure channels are aligned according to a unified time base to form multi-channel time series samples. The internal data representation additionally records the sampling rate and alignment strategy to facilitate subsequent sliding window processing.

[0060] Further, the system performs cleaning processing according to the determined step 1 operator. Outlier handling can employ any or a combination of threshold removal, quantile truncation, or sliding statistical detection; missing value handling can employ one of forward imputation, linear interpolation, or sample discarding. The cleaning operator reads the internal data representation and outputs a data frame of the same format, while simultaneously writing the version and value of the cleaning parameters for this operation. To ensure consistency with the input expectations of subsequent algorithm nodes, the system immediately records the output data format after cleaning, including the number of valid samples per channel and timestamp continuity markers, as the format basis for the input parameters of the next operator.

[0061] Further, the system performs normalization processing according to the determined step 2 operator. The normalization method can be either interval scaling or standardization. For time-series data, the required statistics (such as mean and standard deviation) are calculated independently for each channel, and the generation time identifier and applicable channel set of the statistics are registered in the internal state. The normalized output retains the same dimensions and time identifier as the input and updates the morphological annotations of the internal data representation, indicating the normalized channel domain, facilitating direct consumption by subsequent feature extraction operators.

[0062] Further, the system performs feature extraction according to the determined step 3 operator. For time-series scenarios of fault prediction, feature extraction includes at least one of sliding window slicing, time-domain statistics, and frequency-domain features. Sliding window slicing generates sample segments on the time axis based on window length and stride; time-domain statistics can extract mean, variance, skewness, kurtosis, extrema, and zero crossover rate, etc.; frequency-domain features can calculate the dominant frequency, bandwidth energy ratio, or spectral peak amplitude based on fast transform. The feature extraction operator generates a unified feature vector representation at the output and records the feature dimension, window, and stride parameters in the internal data representation as the basis for expected matching of algorithm node inputs.

[0063] Furthermore, before each operator is executed, the system performs a consistency check between the expected input of the algorithm node and the output of the previous operator, including at least dimension matching, sampling characteristic matching, and window strategy matching. If an inconsistency is found, the system returns the inconsistency item and suggested correction parameters, and suspends the execution of subsequent operators. After all operators have been executed, the system checks again whether the dimension of the final feature vector matches the expected input of the algorithm node, ensuring interface compatibility between the processing chain and the algorithm instance.

[0064] Furthermore, after cleaning, normalization, and feature extraction are completed sequentially and consistency verification passes, the system generates a data processing snapshot. The snapshot content includes at least: the operator sequence order and type, the parameter set and version of each operator, the morphological mapping relationship of the internal data representation (a description of the morphological transformation from the original data to the feature vector), the reference relationship with the configuration snapshot, and the association information with the algorithm nodes. The system simultaneously calculates a snapshot summary and assigns a data processing snapshot identifier, providing this identifier to the training engine and inference engine for subsequent loading, ensuring that the same processing chain and the same set of parameters are used during the training and inference phases.

[0065] For example, in the equipment failure prediction example, the input consists of three types of time-series data: vibration, temperature, and pressure, with sampling rates of 10kHz, 1Hz, and 1Hz, respectively. The operator sequence defined in the configuration diagram is "outlier removal → standardization → sliding window + time-domain and frequency-domain features". The cleaning operator uses quantile truncation to remove vibration spikes and performs linear interpolation on missing temperature and pressure samples; the normalization operator independently standardizes each channel and records the mean and standard deviation; the feature extraction operator uses slices with a window length of 2048 and a stride of 512 on the vibration channel to output statistical and spectral peak features, and outputs short-window statistical features on the low-frequency channel. The system matches and verifies the output feature dimensions with the expected input of the algorithm nodes, generates a data processing snapshot identifier and snapshot summary, and establishes a reference relationship with the configuration snapshot and algorithm nodes for training and inference loading.

[0066] If any operator parameter is changed or the operator type is replaced in the processing chain, the system triggers a difference detection and re-executes the consistency check. After the check passes, a new data processing snapshot identifier is generated, while the old snapshot is retained to support backtracking. For training jobs and inference deployments that depend on historical snapshots, the system accurately loads the corresponding version through the identifier to avoid inconsistencies in the chain caused by parameter drift.

[0067] Through the above embodiments, the system performs data cleaning, normalization, and feature extraction in an operator-driven manner under the configuration diagram, and performs consistency verification with the expected input of the algorithm nodes throughout the process, ultimately forming a referenceable data processing snapshot, thereby achieving unified loading and version management of the same processing link and parameter set in the training and inference stages.

[0068] In some embodiments, the training process is assembled based on the configuration diagram and data processing snapshot, including: The configuration diagram is analyzed to obtain the algorithm nodes, data sources, training parameters and evaluation metric configurations of the training job, and a reference relationship is established with the data processing snapshot; Load algorithm nodes and parameter templates, combine data processing snapshots to determine the form of training inputs and batch processing methods, and initialize training jobs and adjustable parameter whitelists; During training iterations, the system receives parameter adjustment instructions from the visualization configuration module, updates training parameters that belong to the whitelist online, and maintains the continuity of the training state.

[0069] Specifically, the training engine module receives the configuration diagram identifier and data processing snapshot identifier submitted by the visualization configuration module. The training engine parses the configuration diagram, reads the instantiated algorithm nodes, data source descriptions, training parameter sets, and evaluation metric configurations, and establishes a reference relationship with the data processing snapshot. The data source can point to a historical sample set or an online acquisition cache. During the assembly phase, the training engine only records the source identifier and segmentation strategy (training / validation partitioning method, time window constraints), without directly modifying the snapshot content. The evaluation metric configuration includes the selection and calculation frequency of classification or regression metrics, serving as the basis for subsequent metric loading.

[0070] Furthermore, the training engine loads the algorithm entry implementation and parameter template based on the algorithm node identifier. Without altering the data processing snapshot, it determines the form of the training input and the batching method by combining the morphological mapping relationship within the snapshot. For time-series samples, the training engine reads the window length and stride, feature dimensions and channel mapping, and generates a batching strategy (batch size, sequence alignment, padding rules). Based on this, the training engine initializes the data iterator and memory buffer, and checks the consistency between the expected input of the algorithm node and the final feature vector dimension of the data processing snapshot. If they are inconsistent, it returns an assembly failure and correction suggestions, and does not generate a training job.

[0071] Furthermore, the training engine initializes the job based on the set of training parameters in the configuration diagram, including the optimizer, initial learning rate, loss function, upper limit of training epochs, gradient pruning threshold, early stopping policy switch, and monitoring frequency. The training engine also establishes an adjustable parameter whitelist, registering parameters that can be updated online during training as whitelist entries. These whitelist entries must include at least one or more of the following: learning rate, upper limit of training epochs, early stopping threshold, upper limit of batch size, or gradient pruning threshold. The engine sets valid ranges and step constraints for the whitelist entries and records the access channels and permission verification rules for control commands issued by the visual configuration module.

[0072] Furthermore, after entering the training iteration, the training engine extracts samples from the data source according to a batch processing strategy. Following the step order registered in the data processing snapshot, it performs preprocessing mapping on the input consistent with the training (without needing to generate another snapshot), and submits the resulting feature tensors to the training entry point of the algorithm node. After completing a predetermined number of batches or reaching a metric interval, the training engine calculates and reports the evaluation metric and training status to the visualization configuration module. During iteration intervals, the training engine listens for parameter adjustment commands from the visualization configuration module and performs online updates only for whitelisted entries: when a learning rate update command is received, the training engine updates the optimizer's internal learning rate without restarting the job; when a training epoch limit expansion command is received, the training engine adjusts the iteration termination condition; when an early stopping related threshold adjustment command is received, the training engine updates the monitoring criteria and keeps the current cumulative state from being reset. All online updates generate a control event record, which is written to the training record sequence to maintain state continuity.

[0073] Furthermore, the training engine generates training records for each training epoch, which include at least a parameter snapshot summary, data subset identifier, and metric summary for that epoch; it also maintains cumulative statistics and anomaly alert events at the batch level. The training state includes runtime information such as the optimizer's internal state, random number seed, gradient pruning count, and early stopping count, ensuring consistent execution after online parameter updates. To prevent cross-version confusion, the training engine embeds the algorithm node version, parameter template version, and data processing snapshot identifier in the job metadata and establishes a reference relationship between them and the training records.

[0074] For example, in the equipment failure prediction example, the configuration diagram specifies the algorithm node as the target algorithm for time-series modeling, and the data source points to a vibration, temperature, and pressure sample set aligned to a unified time base. The training parameter set provides the initial learning rate, upper limit of training epochs, and batch size. The evaluation metric configuration selects mean squared error and threshold-based classification accuracy. The training engine loads the algorithm node implementation and parameter template, combines the data processing snapshot read window length, stride, and feature dimensions, determines the batch processing method, and initializes the job and whitelist (allowing online adjustment of the learning rate and upper limit of training epochs).

[0075] After training starts, the visualization configuration module issues a learning rate reduction command based on the curve changes, and the training engine takes effect immediately and continues to iterate. When it is close to convergence, an instruction to expand the upper limit of the number of training rounds is issued, and the training engine updates the termination condition and keeps the optimizer state continuous. Parameter update events and metric summaries during the entire training period are written into the training record sequence to provide a basis for the subsequent model package export.

[0076] In some examples, when online parameter updates exceed limits or conflict with the current assembly strategy, the training engine rejects the instruction and returns the reason and valid range. When the data source status is abnormal or inconsistent with the data processing snapshot format, the training engine pauses iteration and issues a consistency alarm, prompting reassembly or a change of snapshot identifier before continuing execution. The training engine supports rollback without destroying the job, restoring the whitelist parameters to the previous valid value and continuing iteration.

[0077] Through the above embodiments, the training engine module completes the assembly and execution of training jobs based on the configuration diagram without changing the data processing snapshot and algorithm node instance. It also supports online updates and continuous state maintenance of whitelist parameters during training iterations, thereby realizing the controllable execution of configuration-driven training process assembly, continuous management of training state, and parameter updates. This lays the technical foundation for subsequent unified export of model packages and consistent loading on the inference engine side.

[0078] In some embodiments, the adjustable parameters during training are updated, the correlation information between parameters, data, and the model is recorded according to the training rounds, and the model package is exported, including: In each training round, a training record is generated, and the parameter set, data subset identifier, model weight identifier and evaluation metric summary of the current round are stored in a fixed manner, and a reference relationship is established with the data processing snapshot and configuration snapshot. When the export conditions are met, a model package is generated and a model identifier is assigned. The model package contains model topology, weights, and dependency information. Register the association information between the model package and algorithm node version, data processing snapshot, and configuration snapshot.

[0079] Specifically, the training engine module establishes an adjustable parameter whitelist when assembling the training process. The whitelist includes at least one or more of the following: learning rate, maximum number of training epochs, early stopping threshold, maximum batch size, or gradient pruning threshold. The visualization configuration module sends parameter adjustment commands to the training engine module through a controlled channel. The command payload includes the parameter name, target value, validity period, and source identifier.

[0080] In some examples, the training engine module performs a three-stage process between batches: first, a validity check, which verifies the parameter name and value range based on the whitelist and parameter template; second, a consistency check, which verifies whether the target value conflicts with the assembly strategy of the current training job; and third, an atomic activation, which writes the parameters that pass the verification into the running state and generates control event records.

[0081] Specifically, for the learning rate, the training engine module directly updates the optimizer's internal state; for the upper limit of the number of training epochs, the training engine module adjusts the termination condition and keeps the historical cumulative state from being cleared; for the early stopping threshold, the training engine module replaces the monitoring criterion and continues to use the existing evaluation sliding window count. If the verification fails, it is rejected and the reason for failure is returned, without affecting the continuity of iteration.

[0082] Furthermore, at the end of each training round, the training engine module generates a training record. This record includes at least a summary of the parameter set for that round, data subset identifiers, model weight identifiers, and a summary of evaluation metrics. Specifically, the parameter set summary records the currently effective adjustable parameter values ​​and key fixed parameter values; the data subset identifier indicates the sample range, time window, or batch range participating in that round of training; the model weight identifier records the unique identifier of the weight snapshot for that round; and the evaluation metric summary records the metric values ​​and sampling frequencies specified in the configuration. These training records are linked to data processing snapshots and configuration snapshots, and a list of control events for that round is simultaneously registered to reconstruct the parameter update history.

[0083] Furthermore, when the export conditions are met, the training engine module generates a model package and assigns a model identifier. Export conditions may include any one or more of the following: reaching the maximum number of training epochs, triggering an early stopping criterion, or an active request from the visualization configuration module. The model package contains model topology, weights, and dependency information. The dependency information records the library versions required for the algorithm implementation, the computation graph serialization format, the random number seed strategy, and necessary running options. The training engine module also associates the model package with the algorithm node version, data processing snapshot, and configuration snapshot, ensuring that the subsequent inference engine module can synchronously load the same data processing chain and parameter set as the training phase when loading the model package, based on the associated information.

[0084] Furthermore, after the model package is generated, the training engine module registers the model identifier and associated metadata in the model registration area. This metadata includes at least the algorithm node version, parameter template version, data processing snapshot identifier, configuration snapshot identifier, training record sequence summary, and export condition summary. After registration, the model package is in a ready state for the inference engine module to load. For subsequent exported model packages, the system retains historical versions and maintains an ordered version index, allowing backtracking to any registered version by model identifier during the inference phase.

[0085] For example, in the equipment failure prediction example, the configuration diagram defines the algorithm node as the target algorithm for time series modeling, and the data processing snapshot provides the link for outlier removal, standardization, and sliding window feature construction. After assembly, the training engine module initializes a whitelist containing the learning rate and the maximum number of training epochs. After training begins, the visualization configuration module first lowers the learning rate based on curve changes, then increases the maximum number of training epochs. The training engine module atomically updates the optimizer's learning rate and termination condition during batch intervals and records control events. At the end of each epoch, the training record is fixed, recording the parameter set summary, the time window of the data subset used, the current weight identifier, and the metric summary for that epoch, while establishing references with the data processing snapshot and configuration snapshot. When the early stopping criterion is triggered, the training engine module generates a model package based on the exported conditions and assigns a model identifier. It registers the model package along with the algorithm node version, the data processing snapshot, and the configuration snapshot identifier simultaneously, so that the inference engine module can retrieve the same data processing chain and parameter configuration according to the identifier when loading subsequently.

[0086] If the target value of an adjustable parameter exceeds the limit or conflicts with the current assembly strategy, the training engine module refuses to apply the parameter and registers the failure event in the training record, without interrupting the iteration. If saving the weights in the current round fails, a retry is performed, and a degradation strategy is triggered after the retry fails, writing the identifier of the most recently successfully saved weights into the current round record and indicating the reason for degradation. When a parameter update error occurs, the training engine module supports rollback according to the previous valid event in the training record during the next batch interval, restoring to the previous valid parameter set before continuing the iteration.

[0087] Through the above embodiments, the system achieves controlled online updates of adjustable parameters during training, and solidifies the correlation information between parameters, data and models at the training round granularity. When the export conditions are met, a model package containing topology, weights and dependency information is generated and a bidirectional association registration with the snapshot is completed, thereby ensuring the traceability, consistent loading and version management of model output and training process.

[0088] In some embodiments, during the training iteration process, the training engine module receives parameter adjustment instructions from the visualization configuration module, updates adjustable parameters, including the learning rate and the upper limit of the number of training rounds, online, and takes effect without restarting the training job; calculates and outputs the loss value, accuracy and / or regression error index at each training round or preset interval in real time, and provides the index sequence to the visualization configuration module for generating training process curve display.

[0089] Furthermore, when assembling the training process, the training engine module automatically determines the data preprocessing steps, sample organization methods, and evaluation metric configurations required for training based on the training process template instructions carried by the target algorithm entries in the algorithm library module and the data processing snapshots, and generates the corresponding training execution process without requiring users to manually write training pipeline code.

[0090] In addition, the training engine module is also used to select the model weights of the target round from the model weights corresponding to multiple rounds based on the parameter set, data subset identifier and model weight identifier fixed by training round, in response to user selection or preset conditions, and register the model package as a deployment candidate version to the model version management module.

[0091] For example, in some examples, the training engine module calculates metrics such as loss, accuracy, and / or regression error in real time at each round or preset batch interval, and sends them to the visualization configuration module through the data channel. The visualization interface generates a training process curve. Based on this curve, the user can issue parameter adjustment commands through the visualization configuration module, including lowering the learning rate and increasing the upper limit of the number of training rounds. The training engine module updates the parameters that belong to the adjustable parameter whitelist online without interrupting the training job.

[0092] During training, the training engine module records the association information of parameter configuration, data subset identifier, and model weight identifier by round. When it is detected that the generalization performance of the model in a certain round meets the preset conditions or the user specifies that round as the target round, the training engine module can directly export the model package based on the model weights of that round for subsequent deployment.

[0093] In some embodiments, the training engine module is further configured to calculate the loss value, accuracy and / or regression error index based on each training round or a preset iteration interval, and provide the information on the change of the index over time to the visualization configuration module for generating training process curves; receive parameter adjustment instructions from the visualization configuration module, and update adjustable parameters, including learning rate and upper limit of training rounds, online, so as to take effect without interrupting the current training job.

[0094] Furthermore, when assembling the training process, the training engine module automatically determines the data preprocessing steps, sample organization methods, and evaluation metric configurations required for training based on the training process template instructions carried by the selected algorithm entries and the operator sequences and data morphology information recorded in the data processing snapshots, generating the corresponding training execution process without requiring users to write training pipeline code.

[0095] Furthermore, the training engine module is also used to: based on the parameter sets, data subset identifiers, and model weight identifiers recorded in each training round, respond to user selections or preset conditions, select the model weights of the target round from the model weights corresponding to multiple training rounds to generate a model package, and register the model package as a deployable model version. For example, when it is found that the model performance in the Nth round is the best, the model package can be directly exported based on the weights of that round as a deployment candidate model.

[0096] In some embodiments, the multi-source data access is parameterized according to the configuration diagram, and online inference is performed to generate inference results, including: Analyze the nodes and parameters related to data access in the configuration diagram, determine the data source type, connection parameters and sampling or polling strategy, and establish the corresponding data input channel; The incoming data is preprocessed in the same way as during training according to the data processing snapshot to obtain inference input that meets the input expectations of the algorithm nodes; Organize inference inputs according to the batch processing or timing window strategy set in the configuration diagram, call algorithm nodes to execute online inference, and generate corresponding inference results.

[0097] Specifically, the inference engine module receives the model identifier and configuration diagram identifier, loads the model package based on the model identifier, and simultaneously loads the data processing snapshot and its morphological mapping information associated with the model package. The inference engine constructs a read-only data processing chain view in memory to ensure consistency with the processing steps and parameters during the training phase.

[0098] Furthermore, the inference engine parses the nodes and parameters related to data access in the configuration diagram, extracting the data source type, connection parameters, and sampling or polling strategy. Data source types may include MQTT sensor channels, OPC interface variables, JDBC database tables, or HTTP aggregation interfaces. For each data source, the inference engine establishes a corresponding data input channel and performs parameterized initialization, such as setting the MQTT server address, port, Topic, and QoS; setting the OPC node path and sampling interval; setting the JDBC data table name, time field, and incremental cursor; and setting the HTTP interface request path, authentication information, and polling cycle. After establishment, each channel enters a warm-up phase, outputting a unified internal data representation.

[0099] Furthermore, to shield against upstream differences, the inference engine unifies the raw data from different channels into an internal data representation, which includes at least the data format, time stamp, and channel identifier; additionally, it records the sampling rate and missing data flags for time-series data. Multi-channel time-series data are aligned according to a unified time base, and an alignment frame is generated using interpolation or alignment strategies without changing the original sampling pattern. The alignment window and boundary processing method are registered in the internal state.

[0100] Furthermore, based on the operator sequences and parameter sets recorded in the data processing snapshot, the inference engine performs preprocessing on the aligned data consistent with the training process, including outlier handling, normalization, and feature extraction. Outlier handling uses the threshold or quantile rules from the snapshot, normalization uses the statistical parameters registered in the snapshot, and feature extraction uses the sliding window length, stride, and feature dimension configurations recorded in the snapshot. To ensure consistency, the inference engine performs morphological verification at each operator input parameter; only if the verification passes can the next operator be proceeded to. If the verification fails, the inference engine records the failure event and discards the batch of data according to the degradation strategy or switches to a waiting state.

[0101] Furthermore, the organization of inference input is completed according to the batch processing or timing window strategy set in the configuration diagram. For timing scenarios of fault prediction, the inference engine generates sample segments by rolling along the time axis according to the window length and step size, and submits them to the algorithm node in a small batch or single sample manner to reduce end-to-end latency. The inference engine maintains a window cursor and buffer internally, and uses a zero-padding or skipping strategy for cross-boundary windows to ensure that the input dimension is consistent with the input expectations of the algorithm node.

[0102] Furthermore, the inference engine calls the inference entry point of the algorithm node to perform online inference on the organized feature vectors and returns the model output vector. The inference engine associates the model output with the corresponding model identifier, data processing snapshot identifier, and configuration diagram identifier to form a traceable inference record. For scenarios requiring multi-model comparison or shadow inference, the inference engine can simultaneously call multiple algorithm nodes on the same input, internally aggregating the results but only outputting the results of the effective model channel.

[0103] For example, in the equipment failure prediction example, the data access nodes are defined as vibration MQTT channels (10kHz), temperature OPC variables (1Hz), and pressure OPC variables (1Hz). The inference engine establishes three types of channels according to configuration parameters and aligns them to a unified time base. Outlier removal, standardization, and sliding window feature construction are performed based on the data processing snapshot. The vibration channel uses a window length of 2048 and a step size of 512 to generate feature fragments, while short-window statistical features are generated and concatenated for the low-frequency channels. Inference input is submitted according to a mini-batch strategy, and the algorithm node returns the failure probability or classification result for each fragment. The inference engine associates the results with model identifiers, configuration diagram identifiers, and data processing snapshot identifiers, allowing external systems to subscribe or poll for retrieval.

[0104] In some examples, when the input channel is disconnected or the latency exceeds the limit, the inference engine retryes or enters a degraded mode according to the configured polling and buffering strategies, and continuously records abnormal events; when the preprocessing morphology verification fails, the inference engine refuses to submit inconsistent inputs and maintains the continuous generation of subsequent windows to avoid overall interruption; when the model package version is switched, the inference engine completes a seamless replacement at a window boundary to ensure that the new data processing snapshot and model weights are used after the switching point.

[0105] The inference engine encapsulates the inference results into a unified output object, including time identifiers, channel identifiers, model identifiers, and result vectors. It provides subscription and query interfaces, supporting external industrial control systems to retrieve results on demand or based on event pushes. For projects requiring alarm linkage, the inference engine only outputs the inference result body; rules and alarm logic are configured and executed separately by upper-layer modules according to the configuration diagram.

[0106] Through the above embodiments, the inference engine module completes the parameterized configuration of multi-source data access under the constraints of the configuration diagram, performs preprocessing consistent with training based on data processing snapshots, and organizes inference input according to window and batch processing strategies to call algorithm nodes to generate inference results, thereby realizing end-to-end consistent loading, loosely coupled access and traceable output of the inference link.

[0107] In some embodiments, the inference engine module is configured to be deployed on an edge gateway or a local industrial server, loading model packages and their associated data processing snapshots without relying on a complex container orchestration environment, and directly acquiring data from multi-source data channels in the field based on the configuration diagram and performing online inference.

[0108] Furthermore, the inference engine module is deployed in a lightweight runtime form on an edge gateway or local server close to the production line. It loads the corresponding model package and data processing snapshot through configuration diagrams and model identifiers, and can directly connect to field data sources such as MQTT, OPC, and databases to perform real-time inference without relying on complex container orchestration clusters.

[0109] Furthermore, the inference engine module is used to subscribe to or receive effective model identifiers issued by the model version management module. Without interrupting the inference service, it loads the corresponding model package and data processing snapshot at the preset switching boundary and completes the model switching. When an anomaly of the target model is detected, it switches back to the historical effective version with one click according to the rollback command.

[0110] In some embodiments, the inference engine module is configured to be deployed in a lightweight manner on an edge gateway or local industrial server. Without relying on a complex container orchestration environment, it acquires real-time data from multiple data channels in the industrial field based on the configuration diagram, loads model packages and associated data processing snapshots, and performs online inference in a small batch or streaming manner to reduce end-to-end latency.

[0111] Furthermore, the inference engine module is also used to receive the effective model identifier and its associated data processing snapshot identifier issued by the model version management module, preload the target model package and data processing snapshot at the batch processing boundary or time window boundary of the current inference task, and switch to the target model for inference at the boundary, thereby completing the model version switch without interrupting the inference service; when an inference anomaly of the target model is detected or a rollback instruction is received, the module switches back to the historical effective model version at the boundary.

[0112] In some embodiments, the system further includes: The model version management module is used to store model packages in a versioned manner, associate model packages with corresponding data processing snapshots, provide effective version selection and version switching control, and issue the model identifier corresponding to the currently effective model package to the inference engine module.

[0113] Specifically, the training engine module generates a model package and assigns a model identifier when the export conditions are met. The model version management module receives the model package and executes the storage process, which includes: model topology summary, weight summary, dependency information summary, training record summary, export condition summary, algorithm node version, parameter template version, data processing snapshot identifier, and configuration snapshot identifier. To ensure immutability, the module adopts an append-only versioning strategy: the same algorithm node under the same project forms a time-ordered version chain, generating a completely new version number and index entry each time it is stored, while historical versions are retained and can be accurately referenced. After storage is complete, the module calculates an integrity check value and registers the storage time, submitter, visibility scope, and access permissions for subsequent effectiveness control and audit queries.

[0114] Furthermore, to ensure consistency between the training and inference chains, the model version management module enforces a mandatory verification of the correspondence between the model package and the data processing snapshot upon loading. This verification includes: 1) verifying that the data processing snapshot identifier recorded within the model package matches the snapshot record in the repository; 2) verifying that the snapshot summary (operator sequence, parameter set, morphological mapping relationship) has not been tampered with; and 3) verifying that the expected input of the algorithm node matches the snapshot output dimension. Upon successful verification, a reference chain of "model identifier → data processing snapshot identifier → configuration snapshot identifier" is established in the version index, serving as the sole basis for loading the inference engine module. If any verification fails, the module refuses to load the model and returns the reason for the failure and any conflicts, preventing the creation of unusable versions.

[0115] Furthermore, the model version management module provides an effective version selection function, supporting three selection strategies: fixed selection, rule-based selection, and approval selection. Fixed selection allows authorized users to select the target model identifier in the interface and submit an effectiveness request; rule-based selection automatically recommends candidate versions based on pre-registered filtering conditions (such as indicator thresholds in the training record summary and trigger types in the export condition summary); approval selection is used in multi-role collaboration scenarios, where an effective application is submitted and confirmed by a designated reviewer. Regardless of the strategy, a second consistency check is required before submission for effectiveness to ensure that the data processing snapshot corresponding to the target model identifier is still available and not disabled. After effectiveness confirmation, the module generates an "effectiveness instruction," which includes the effective model identifier, the effective time point, and the switching strategy, and writes it to the audit log.

[0116] Furthermore, the model version management module supports two modes: immediate switching and targeted switching. Immediate switching is suitable for offline batch inference or scenarios insensitive to latency. Upon receiving the activation command, the module immediately issues the effective model identifier to the inference engine module. Targeted switching is suitable for online time-series inference scenarios. The module calculates the switching boundary (such as the time-series window boundary or batch processing boundary) according to the window strategy registered in the configuration diagram, and issues the effective model identifier and its associated data processing snapshot identifier all at once when the boundary is reached. The issuance adopts atomic broadcast semantics: it issues the switch to multiple inference instances within the cluster using the same transaction number, requiring each instance to complete the synchronous loading of the model and snapshot at the same boundary point; before any instance confirms, the module keeps the old version in an effective state and performs retries or rollbacks. To avoid resource thrashing, the module supports a pre-loading strategy: before the switch, the new version reference is pre-distributed in the window, and the inference instance completes loading and dependency verification in the background, only performing handle switching at the boundary point.

[0117] Furthermore, the module provides rollback and canary rollout capabilities. Rollback is used when a new version is determined not to meet business-side release conditions during operation; the module can restore the previous stable version with one click. Canary rollout is used to verify the reliability of the new version on a small scale. The module supports configuring the activation ratio by channel or instance, with the old and new versions running in parallel. The module continuously collects operational metrics and anomaly summaries, but only outputs the results of the main effective channel. After the canary rollout is complete, users can submit "full activation" or "rollback" commands, and the module will complete the final version switch and archive the comparison data during the canary rollout.

[0118] Furthermore, the model version management module exposes two types of interfaces: subscription-based and pull-based. The subscription-based interface is used for online inference scenarios. The inference engine module subscribes to the model activation event of the target project, and pushes an activation message containing the model identifier and data processing snapshot identifier when switching versions. The pull-based interface is used during the startup phase or abnormal recovery. The inference engine module can request the currently active version based on the project identifier. After receiving the activation message, the inference engine loads the model package according to the model identifier and synchronously loads the associated data processing snapshot. It then verifies the consistency of the preprocessing parameters by comparing the snapshot format mapping. If the verification fails, the inference engine refuses to switch and returns a failure reason, which triggers a rollback strategy.

[0119] For example, in a device failure prediction project, models V1 and V2 are exported sequentially during the training phase. Both have the same algorithm node version, but V2 is derived based on the expanded epochs and adjusted learning rate. After the model version management module completes the data entry, it displays the version chain and the associated snapshot identifier of the same data processing. The operations and maintenance personnel select "fixed-point switch to V2," with the switch boundary being the vibration channel window boundary (length 2048, stride 512). Before reaching the boundary, the module preloads the new version onto the inference instances within the cluster; upon reaching the boundary, an effective message is atomically issued, and the switch is completed after all instances confirm. If the monitoring system reports frequent anomalies during operation, the operations and maintenance personnel trigger a rollback. The module atomically switches back to V1 at the next window boundary and retains V2 in the shadow channel in grayscale mode for subsequent troubleshooting.

[0120] In some examples, to meet the audit requirements of industrial sites, the model version management module generates audit entries for key events such as import, selection, switching, rollback, and gray-scale deployment. These entries include the event time, operator, target model identifier, associated snapshot identifier, switching strategy, and instance confirmation result. Audit entries are saved in read-only mode and can be retrieved by project dimension for integration with external compliance systems.

[0121] If an inference instance fails to load the new version within the switching window, the module performs a degradation based on the number of retries and the timeout threshold: First, the old version remains in effect until the next switching boundary; second, if some instances have already switched, the module forces them to revert to the old version to ensure cluster consistency. For dependency verification failures or inconsistent snapshots, the module marks the target version as "frozen," preventing it from being selected as the effective version again, and unfreezing it only after the training side re-exports a compliant model.

[0122] Through the above embodiments, the model version management module realizes the immutable versioned storage of model packages and strong association with data processing snapshots. It provides atomic switching and pre-loadable fixed-point switching control for online scenarios, supports runtime management capabilities such as grayscale and rollback, and ensures consistent loading and traceable operation of the inference end through the issuance of effective messages and audit trails, thereby realizing the safe, reliable and controllable management of model versions in industrial sites.

[0123] In some embodiments, the system further includes: The rule configuration module is used to configure the output format and rules of the inference results according to the configuration diagram, generate output data and alarm commands, and provide the output data and alarm commands to the external industrial control system through the external interface.

[0124] Specifically, the rule configuration module provides metadata management for rule templates and output templates within the engineering-level project space. Rule templates describe triggering conditions, time windows, debouncing strategies, synthesis strategies, and action mappings; output templates describe the result presentation format and field mappings. A rule entry must include at least: a rule identifier, the target object (model identifier or inference channel), input field descriptions (e.g., fault probability, category label, feature fragment time range), conditional expression, time window parameters, duration threshold, deduplication and rate limiting parameters, action list, and priority. Output templates must include at least: visualization type (dashboard, trend curve, image annotation), field-to-presentation element mapping, sampling and aggregation methods, and unit and decimal place configurations. All templates include version numbers and are referenced in the configuration diagram to ensure consistency with the currently active model and data processing snapshot.

[0125] Furthermore, after selecting the inference result output node on the canvas, the visualization configuration module loads the parameter forms of the rule template and the output template. Users configure trigger conditions and output styles using human-readable expressions. For example, they can enter "fault probability > 0.8 and 3 consecutive times" into the condition editor and the graded color scale of "device status = warning / fault" into the output template. When saving, the system compiles the expression into an abstract syntax tree, verifies whether the participating fields exist in the output mode of the inference engine module, whether the units and dimensions are consistent, and establishes reference relationships with the corresponding model identifier, data processing snapshot identifier, and configuration diagram identifier. For image detection results, the output template can declare an "image annotation" type and map the detection box coordinates, category, and confidence fields.

[0126] Furthermore, the rule configuration module performs consistency checks before submission, including at least: field existence and type verification, condition expression parsing verification, time window and sampling strategy matching verification, and action channel reachability verification. After successful verification, the module generates snapshot identifiers for both the rule set and the output template, and records the association information with the configuration diagram, the currently effective model identifier in the model version management module, and the data processing snapshot identifier, forming a traceable "rule snapshot." Any subsequent changes generate a new snapshot, while old snapshots are retained to support rollback.

[0127] Furthermore, the inference engine module pushes each inference result, along with the model identifier, data processing snapshot identifier, and configuration diagram identifier, to the evaluation entry point of the rule configuration module. The rule configuration module extracts fields and aligns dimensions based on rule snapshots, maintaining time window states in memory, such as sliding window counts, consecutive counts, dejitter timers, and rate limit counts. Conditional expressions are evaluated event-by-event: first, threshold judgment and Boolean synthesis are performed, then secondary criteria such as "consecutive counts ≥ threshold" and "proportion within the time window ≥ threshold" are applied. Multiple rules for the same device channel are evaluated from highest to lowest priority, and a mutual exclusion strategy is supported to prevent duplicate alarms.

[0128] Furthermore, upon rule triggering, the module generates alarm commands and output data based on the action mapping. Action types include at least: audible and visual alarms, SMS / email, Webhook push notifications, industrial protocol writing (such as writing status words to the upper-level system via a gateway), and local log persistence. The module generates a unique trigger identifier for each trigger, including the device channel, time range, rule identifier, and model identifier, and sends it outwards with idempotent semantics to prevent duplicate processing. The external interface uses a unified message structure: timestamp, device identifier, model identifier, rule identifier, alarm level, summary field, and original result reference. If the external system requires visualization, the module generates object-oriented output based on the output template, such as the scale values ​​and color mapping of a "fault probability dashboard," the sampling point sequence of a "trend curve," or the set of bounding box coordinates and category descriptions for "image annotations."

[0129] Furthermore, when the model version management module completes the effective version switch, the rule configuration module receives the effective message and verifies whether the fields on which the rule snapshot depends still exist in the new model output and whether their dimensions are consistent. If they are inconsistent, the module sets the relevant rules to pending repair and blocks triggering to avoid error alarms. If they are consistent, the rules continue to be evaluated on the new model output. For point-to-point switching, the module synchronously switches its internal field mappings at the switching boundary, ensuring that all evaluations after the boundary are based on the new model and the new data processing snapshot.

[0130] For example, in a fault prediction project, the user configures two levels of rules for the vibration channel: a warning level "fault probability > 0.6 and 3 consecutive occurrences" and a fault level "fault probability > 0.8 and 3 consecutive occurrences". The time window is the last 5 windows, the de-jittering time is 60 seconds, and the rate is limited to a maximum of once per device every 5 minutes. The output template is configured as "dashboard + trend curve". The dashboard scale is divided into three segments: green, yellow, and red, from 0 to 1. The trend curve sampling window is consistent with the inference window.

[0131] During runtime, the inference engine module outputs fault probabilities and category labels, while the rule configuration module performs continuous counting and threshold judgments as the window scrolls. When triggered, it generates alarm commands and pushes them to the external industrial control system via Webhook, while simultaneously returning dashboard values ​​and trend segments for the front-end dashboard. If the model version is switched to V2 and the output field names remain unchanged, the rules continue to be evaluated based on the V2 results; if the field names or dimensions change, the module freezes the rules at the switching point and records a prompt, which takes effect only after the user has revised them.

[0132] In some examples, when inference results are missing or delays exceed limits, the module retains the continuous count but pauses the advancement window until a timeout threshold is reached, at which point the current count is downgraded to a boundary state. When an external action channel is unreachable, the module retryes and, after exceeding a threshold, downgrades the action to a local log file, while retaining the trigger identifier for subsequent resending. When a rule expression update causes incompatibility with existing fields, the module refuses to apply the new snapshot and returns conflicting fields and suggested mappings.

[0133] The rule configuration module audits and logs rule snapshot generation, activation, freezing, and triggering events. The logs include the rule identifier, snapshot identifier, trigger time, input summary, action result, and external confirmation status. The trigger identifier allows for replaying the inference output and rule evaluation path during subsequent investigations, pinpointing threshold settings or field mapping issues.

[0134] Through the above embodiments, the rule configuration module realizes the output form of inference results and the visualization configuration of rules, expression compilation and consistency verification, runtime time window evaluation and debouncing control, action mapping and idempotent distribution under the constraints of the configuration diagram. It also maintains field-level alignment and rollback capability with model version switching, thereby completing configurable result presentation and alarm linkage without modifying the inference engine module, ensuring end-to-end consistent loading, low-coupling integration and traceable management.

[0135] In some embodiments, the rule configuration module is connected to the inference engine module and is used to perform condition judgment and time window statistics on the inference results output by the inference engine module based on the configuration diagram and rule snapshot, generate structured alarm instructions and output data, and send them to the industrial control system or upper monitoring platform through the external interface.

[0136] Specifically, after completing model training, model package export, and inference engine deployment, the rule configuration module provides a rule configuration interface based on the configuration diagram of the same project. Users can select the inference result output node in the visual configuration interface and configure its rule conditions and output format, including: target model identifier, device or channel range, result fields involved in the calculation (such as fault probability, classification label, defect type), time window length, consecutive trigger threshold, alarm level, and target output channel.

[0137] After user configuration, the system parses and verifies the rules, then saves them as rule snapshots. Each rule snapshot records at least: the rule identifier, the bound configuration diagram identifier, the bound model identifier, the data processing snapshot identifier, input field names and type descriptions, time windows and counting strategies, output data templates, and alarm action configurations. This rule snapshot establishes a one-to-one correspondence or compatibility association with the aforementioned configuration snapshots, model versions, and inference engine output formats to ensure consistency between subsequent rule evaluation and inference data structures.

[0138] After completing online inference, the inference engine module organizes each inference result into a structured output object, which includes at least: timestamp, device or channel identifier, model identifier, data processing snapshot identifier, configuration diagram identifier, and inference result fields (such as fault probability value, prediction category, defect location coordinates, etc.). The above output is forwarded to the rule evaluation engine of the rule configuration module through an internal message channel.

[0139] The rule evaluation engine selects a matching set of rule snapshots based on the model identifier and configuration diagram identifier contained in the inference result. It only parses and executes the rules that are bound to the current inference result, thereby avoiding cross-interference between different projects or different models and ensuring that the scope of the rule corresponds strictly to the source of the inference result.

[0140] In some examples, the rule configuration module builds runtime state for each rule snapshot, including a time window buffer queue, a continuous trigger counter, a dejitter timer, and a frequency limiting control counter. For each incoming inference result, the rule evaluation process includes: Field extraction: Based on the field names recorded in the rule snapshot, extract the failure probability, label, confidence level, or other values ​​that need to be used for judgment from the inference result object.

[0141] Conditional calculation: Perform threshold judgment and logical operations based on the rule expression, such as "fault probability > 0.8 and the predicted label is 'abnormal'".

[0142] Time window processing: Insert the inference results that meet the conditions into the corresponding time window queue, remove historical records that are outside the time window range, and count the number or proportion of valid records in the current time window, such as "the conditions are met at least 3 times in the last 5 inference windows".

[0143] Consecutive count and debouncing control: The count of inference results that continuously meet the conditions is increased. When the count reaches the consecutive threshold required by the rule, it is marked as triggered. At the same time, according to the debouncing time setting, the repeated triggering of the same rule on the same device is suppressed within a certain period of time.

[0144] Through the above steps, the rule configuration module performs multi-dimensional and time-continuous composite judgments on the inference results without changing the internal inference logic of the inference engine.

[0145] Furthermore, when the triggering condition of a rule is met, the rule configuration module generates structured output data and alarm instructions based on the output template in the rule snapshot. The output data includes at least: trigger time, device or production line identifier, corresponding model identifier, rule identifier, key field values ​​(such as current fault probability, number of consecutive anomalies), time window statistics, and reference information of the original inference results.

[0146] Alarm commands are organized according to the configured action type. For example, a "high-priority fault warning" message is generated for the upper-level monitoring platform; a "write to a register or variable" command is generated and sent to the PLC or DCS through the industrial protocol gateway; or an HTTP / Webhook message is generated and pushed to the enterprise operation and maintenance platform. All alarm commands are bound to a unique trigger identifier when generated to achieve idempotent processing and subsequent audit tracing.

[0147] For example, taking a fault prediction scenario, the inference engine periodically outputs the "fault probability" and "predicted status" for each device. The rule configuration module configures two levels of rules for this project: Rule 1 (Warning): For a single device, a warning is generated when the probability of failure is greater than 0.6 for three consecutive inference cycles. Rule 2 (Critical Fault): A critical alarm is generated when the fault probability is greater than 0.8 for three consecutive inference cycles.

[0148] The rule snapshot is explicitly bound to the corresponding model identifier and output field name, with a time window set to the most recent 3 inference cycles and a debouncing time of 60 seconds. During runtime, the rule configuration module maintains an independent time window and counter for each device. When rule 1 is met, an early warning message is sent to the upper-level monitoring platform. When rule 2 is met, in addition to the early warning, an audible and visual alarm or shutdown linkage is triggered via the industrial protocol interface. All trigger records include the model identifier, data processing snapshot identifier, and configuration diagram identifier, facilitating subsequent verification of "which version of the model and data processing flow the alarm was based on."

[0149] When the model version management module switches or rolls back a model version, the inference engine module loads the new model package and associated data processing snapshot and updates the output field definitions. The rule configuration module compares the output structure of the new and old models based on the field binding information in the rule snapshot: if the fields and semantics remain compatible, the rule evaluation can continue seamlessly; if there are missing fields or changes in meaning, the rule configuration module will automatically mark the relevant rules as pending revision and pause triggering to avoid error alarms caused by model switching, thus achieving collaborative control between rules and model versions.

[0150] Through the above embodiments, the rule configuration module and the inference engine module form a tightly coupled rule calculation link: under the same configuration diagram and rule snapshot constraints, field-level parsing, time window statistics and continuous condition judgment are performed on the inference results to generate structured and traceable output data and alarm instructions. And through standardized interfaces, it connects with industrial control systems or upper-level monitoring platforms, thereby realizing configurable mapping and stable linkage from inference results to business alarms without modifying the model inference logic, improving the manageability and engineering applicability of the system in industrial scenarios.

[0151] The above embodiments provide a detailed description of the framework structure and functions of the configurable artificial intelligence application system for industrial automation of this application. The following uses a practical application scenario of industrial equipment fault prediction as an example to explain in detail the specific implementation of the configurable AI application framework of this application.

[0152] First, requirements analysis: A factory wants to predict potential equipment failures in advance by analyzing equipment operating data, so as to carry out timely maintenance and reduce downtime. Equipment operating data includes sensor data such as temperature, pressure, and vibration.

[0153] Furthermore, algorithm selection and configuration: In the visual configuration interface, users select suitable algorithm components from the AI ​​algorithm library. Then, they set the component parameters, such as the number of hidden layer nodes, the number of layers, and the learning rate.

[0154] Furthermore, the data processing workflow is configured as follows: Since there is noise in the sensor data, the user first selects a data cleaning algorithm to remove outliers, and then performs normalization processing to scale the data to an appropriate range.

[0155] Further, training configuration: The user specifies the training and validation datasets, and sets training parameters such as the number of training epochs and the learning rate of 0.001. The training engine trains the model based on these parameters, and displays the accuracy and loss curves in real time on the visualization interface during the training process.

[0156] Further, inference configuration and application: After training, the user deploys the trained model to the inference engine and configures the inference engine to receive the latest operational data from the device in real time. The inference engine uses the model to infer from the data and predict whether the device is about to malfunction. The inference results are displayed visually on the monitoring interface. When a potential device malfunction is predicted, the system issues an early warning signal to remind operators to take timely measures.

[0157] Through the above implementation methods, this configurable AI application framework can meet the needs of industrial equipment fault prediction, and achieve efficient artificial intelligence applications through flexible configuration and visualization.

[0158] The configurable AI application framework of this application achieves several significant technical effects, greatly promoting the development of industrial automation software in the field of artificial intelligence applications. The technical solution of this application has at least the following advantages: I. Enhance the flexibility of AI application customization Traditional industrial automation software employs a fixed algorithm integration model, which struggles to meet the diverse needs of different industrial scenarios. This patent, through a visual configuration interface, allows users to easily select suitable algorithms for specific industrial tasks from a rich AI algorithm library, much like building blocks. For example, convolutional neural networks can be used in industrial quality inspection, while Long Short-Term Memory (LSTM) networks can be employed for equipment fault prediction. Users can also independently set key algorithm parameters, such as the number of layers, nodes, and learning rate of the neural network. In the data processing stage, users can freely build data processing workflows based on the characteristics of industrial data, selecting and configuring parameters for processing steps such as data cleaning, normalization, feature extraction, and serialization, ensuring a precise fit between the data processing workflow and algorithm requirements and data characteristics. This flexible configuration approach enables industrial enterprises to quickly customize personalized AI applications based on their unique production processes, data types, and business objectives, meeting the complex and ever-changing needs of different scenarios. It breaks free from the constraints of traditional fixed models, significantly improving the customization and applicability of AI applications.

[0159] II. Lowering the barriers to AI technology application For many operators in the industrial sector without AI expertise, the traditional AI model training and deployment process is a formidable obstacle, involving complex coding, specialized algorithm knowledge, and tedious parameter tuning, severely hindering the widespread application of AI technology in industrial automation. This patent provides a visual configuration interface that transforms the complex AI application setup process into a simple and intuitive graphical operation. Users can easily configure AI applications by simply dragging and dropping algorithm icons and setting parameters, without writing complex code. The training engine automatically executes the training process based on the user-configured parameters and provides real-time feedback on key indicators such as training progress, accuracy, and loss value on the visual interface. Users can intuitively judge the training effect and adjust training parameters in a timely manner. This "what you see is what you get" operating mode allows industrial personnel lacking AI expertise to quickly get started, integrating AI technology into actual production and powerfully promoting the widespread application of AI technology in the industrial field.

[0160] III. Improving the Efficiency of Industrial Data Processing and Analysis Industrial data is characterized by its diversity, complexity, and massive volume. Traditional industrial automation software's fixed data processing workflows are insufficient to effectively handle the processing needs of different data types. This patented data processing module supports various preprocessing operations, allowing users to freely configure the data processing workflow in a visual interface and select the most suitable processing steps for different data characteristics. For time-series data collected by sensors containing significant noise, data cleaning is performed to remove outliers, followed by normalization, and finally, serialization is performed according to algorithm requirements, organizing the data into a format suitable for model training. This flexible and customizable data processing workflow significantly improves data quality, providing a solid foundation for subsequent AI algorithm training and inference, effectively enhancing the efficiency and accuracy of industrial data processing and analysis, and ultimately improving the performance of AI models in industrial scenarios.

[0161] IV. Achieving Intelligent Decision-Making and Control By deploying trained AI models into industrial control systems through an inference engine, rapid inference and prediction can be performed on real-time collected industrial data. In industrial equipment condition monitoring scenarios, the inference engine analyzes equipment operating data based on the trained model, quickly determining whether the equipment is in a normal state. Once a potential equipment failure is predicted, an early warning signal is immediately issued to the operator, reminding them to take timely maintenance measures, effectively avoiding production interruptions caused by sudden equipment failures and reducing enterprise losses. In industrial production quality inspection, the inference results can visually display the location and type of detected defects through image annotations and other intuitive methods, providing accurate basis for optimizing and adjusting the production process. This intelligent decision-making and control capability helps industrial enterprises achieve refined management of the production process, improve production efficiency, enhance product quality, and strengthen their competitiveness in the market.

[0162] The above embodiments have described in detail the specific modules and functions of the configurable artificial intelligence application system for industrial automation of this application. The implementation process of the configurable artificial intelligence application method for industrial automation of this application will be described in detail below with reference to specific embodiments. Figure 2 This is a flowchart illustrating a configurable artificial intelligence application method for industrial automation provided in an embodiment of this application, such as... Figure 2 As shown, this configurable artificial intelligence application method for industrial automation may specifically include the following steps: S201, in the visualization configuration module, graphical arrangement is performed to generate a configuration diagram containing node, connection and parameter information, the configuration diagram is checked for consistency and stored in a versioned manner to form a configuration snapshot; S202: Select algorithm entries from the algorithm library module according to the configuration diagram, generate instantiated parameter sets according to the parameter template, and create algorithm nodes; S203, the data processing module parses the configuration diagram to determine the sequence of data processing operators, receives industrial data and sequentially performs data cleaning, normalization and feature extraction, and generates a data processing snapshot associated with the configuration snapshot; S204 is a training engine module that assembles the training process based on the configuration diagram and data processing snapshot, loads the algorithm nodes and initializes the training parameters, updates the adjustable parameters online according to the parameter adjustment instructions, records the correlation information between parameters, data and model according to the training rounds and exports the model package. S205 loads the model package and associated data processing snapshots by the inference engine module, performs parameterized configuration of multi-source data access according to the configuration diagram, performs preprocessing on the accessed data according to the data processing snapshots, and calls the algorithm node to perform online inference to generate inference results.

[0163] Specifically, S201: Graphical arrangement, verification, and versioned storage of configuration diagrams. In the canvas of the visualization configuration module, users drag and drop data processing nodes and algorithm nodes from the component panel to the workspace, forming a directed data flow through port connections, and entering parameters in the property panel. The system freezes the interaction into a configuration diagram in real time. The configuration diagram includes at least: a node set (recording node identifier, type, input / output port description, and parameter entries), a connection set (recording source / target ports, data form constraints, and sampling attributes), and a parameter set (including key name, type, default value, value range, unit, and whether it is required).

[0164] When a configuration diagram is submitted, the system generates parameter constraints and dependency descriptions within the diagram based on the parameter templates and data processing flow templates attached to the algorithm entries, and performs consistency checks: matching connection directions and port types, matching data formats and sampling characteristics, valid required parameters and their value ranges, and complete upstream / downstream dependencies. After successful checks, a structure summary is calculated for the configuration diagram and versioned for storage, with a configuration snapshot identifier assigned. During storage, the system also records the association information with the algorithm entry version, parameter template version, and data processing flow template version. Any modifications will generate a new snapshot; historical snapshots are read-only.

[0165] Furthermore, S202: Algorithm entry selection, parameter instantiation, and algorithm node creation. The system parses the placeholder information of the selected algorithm node in the configuration diagram, locates the corresponding algorithm entry in the algorithm library module, and reads the metadata of the entry (applicable task type, expected input form, supported evaluation metrics) along with parameter templates and data processing flow template instructions. Based on the parameter templates, the system aligns and completes the user input with default values ​​to form an instantiated parameter set. The data processing flow template instructions are written into the dependency domain of the configuration diagram to constrain the upstream processing operators.

[0166] Before creating an instance, three types of consistency checks are performed: First, input form check—the feature dimensions, window, and sampling characteristics of the current upstream output of the configuration diagram should be consistent with the expected input of the algorithm entry; second, parameter validity check—the required fields, types, and ranges are checked according to the template; third, dependency integrity check—the pre-operators indicated by the template already exist in the diagram and are in the correct order. After the checks pass, an algorithm node instance is generated, registering the algorithm entry version, parameter template version, and data processing flow template version, and establishing a reference relationship with the configuration snapshot for loading according to node identifiers during the training and inference phases.

[0167] Furthermore, S203: Execution of data processing operator chain and generation of data processing snapshot. The data processing module parses the data processing nodes and directed connections in the configuration diagram, determines the operator sequence by topological sorting (e.g., outlier / missing value handling → normalization → feature extraction / serialization), and aggregates the parameter sets of each operator, establishing a reference relationship with the configuration snapshot. The module receives data from industrial data sources (such as MQTT, OPC, JDBC, or HTTP interfaces), unifies it into an internal data representation, and records at least the data format, time stamp, and channel identifier. For time-series data, the sampling rate and alignment strategy are additionally recorded.

[0168] The process then proceeds sequentially according to the operator sequence: The cleaning phase handles anomalies / missing data using strategies such as thresholding, quantile truncation, and sliding statistics; the normalization phase performs interval scaling or standardization and registers the source of statistics; the feature extraction phase slices data by window length and stride, outputting time-domain statistics or frequency-domain spectral features. At each operator entry point, the input morphology is checked for consistency with the expected input of the algorithm node; if a failure occurs, a conflict item is returned and the process is blocked. After the process successfully completes, a data processing snapshot is generated. This snapshot records at least the operator sequence and parameters, the morphological mapping relationship (original → feature), and the association information between the configuration snapshot and the algorithm node, and is assigned a data processing snapshot identifier for reference in subsequent steps.

[0169] Furthermore, S204: Training assembly, online parameter updates, and model package export based on configuration snapshots and data processing snapshots. The training engine module receives configuration snapshot identifiers and data processing snapshot identifiers, parses the configuration diagram to obtain the algorithm nodes, data sources, training parameters, and evaluation metric configurations, and establishes a reference with the data processing snapshot. The training engine loads the algorithm node implementation and parameter template, determines the training input format and batch processing method based on the data processing snapshot, initializes the optimizer, loss function, training epoch limit, early stopping strategy, etc., and establishes a whitelist of adjustable parameters (such as at least one of the following: learning rate, training epoch limit, early stopping threshold, batch size limit, or gradient clipping threshold).

[0170] During training iterations, the training engine extracts samples from the data source in batches, performs consistent preprocessing mapping based on the data processing snapshot, and then submits them to the algorithm node training entry. During iteration intervals, it listens for parameter adjustment commands from the visualization configuration module, updating only whitelisted entries online and maintaining continuous runtime (e.g., directly updating the optimizer learning rate, expanding the training epoch limit without restarting the job). At the end of each training epoch, the training record is solidified, recording the parameter set summary, data subset identifier, model weight identifier, and evaluation metric summary for that epoch, and establishing references with the data processing snapshot and configuration snapshot. When the export conditions are met (reaching the epoch limit / early stop trigger / manual request), the model package is exported and a model identifier is assigned. The model package contains at least model topology, weights, and dependency information, and registers the association information with the algorithm node version, data processing snapshot, and configuration snapshot, entering a deployable state.

[0171] Furthermore, S205: Parameterized configuration of inference loading and multi-source data access, and online inference execution. The inference engine module loads the model package based on the model identifier and simultaneously loads the associated data processing snapshot, constructing a read-only preprocessing link view. It then parses the data access nodes in the configuration diagram, establishes input channels according to data source type and connection parameters, configures sampling or polling strategies, and outputs a unified internal data representation.

[0172] For the incoming data, the inference engine strictly performs preprocessing according to the operator sequence and parameters recorded in the data processing snapshot, including outlier handling, normalization (using training-period statistics), and feature extraction (using window and stride). Morphological verification is performed at each operator entry point to ensure consistency with the input expectations of the algorithm nodes. Inference input is organized according to the batch processing or time-series window strategy set in the configuration diagram. Online inference is executed by calling the inference entry point of the algorithm node to generate inference results. Inference records are associated with model identifiers, data processing snapshot identifiers, and configuration snapshot identifiers for subsequent auditing, visualization, and rule evaluation. For projects requiring multi-version governance, point-to-point switching or gray-scale deployment can be performed under the control of the model version management module. The inference engine atomically completes the synchronous replacement of the old and new models and snapshots at the window boundary.

[0173] For example, in some typical examples, taking equipment failure prediction as an example: In S201, configure "anomaly / missing information handling → standardization → sliding window features → time-series algorithm nodes" and form a configuration snapshot; S202 select the target algorithm entry and instantiate the parameter set; S203 generate a data processing snapshot, recording the window length, stride, and feature dimension; S204 assemble the training and adjust the learning rate and expand the number of training rounds in the iteration, report the training records, and export the model package; S205 establish MQTT / OPC channels at the edge nodes, align with the time base, generate feature fragments according to the snapshot link, submit inference in small batches, and produce the result vector for each window. If the version management command requires a switch, the inference engine atomically switches to the new model and its associated snapshot at the next window boundary.

[0174] Failure of form / dependency verification at any stage will block that stage and return conflict items and rectification suggestions; online parameter updates that exceed limits or conflict with assembly strategies will be rejected and the event will be logged; on the inference side, when the input channel is abnormal or the preprocessing is inconsistent, it will enter degrade mode, retain the window cursor, and continue after recovery.

[0175] Through the implementation of steps S201 to S205 above, an end-to-end method flow with configuration diagram as the core is completed: the graphical arrangement is solidified into a configuration snapshot, which drives the instantiation of algorithm nodes and the generation of data processing snapshots. During the training phase, controllable online parameter updates and traceable recording are achieved and the model package is exported. During the inference phase, multi-source access, unified preprocessing and online inference execution are completed based on the same data processing snapshot, ensuring consistent loading, low coupling collaboration and version management of the training / inference link.

[0176] It should be understood that the sequence number of each step in the above method embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0177] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although the technical solutions of this application have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A configurable artificial intelligence application system for industrial automation, characterized in that, include: The visualization configuration module is used to provide graphical arrangement operations and generate configuration diagrams. It performs consistency verification and versioned storage on the configuration diagrams to form configuration snapshots. The configuration diagrams include node, connection and parameter information. The algorithm library module is used to provide algorithm entries with a unified calling interface, and is selected and instantiated as algorithm nodes according to the configuration diagram. The algorithm entries carry the required data processing flow template and parameter template. The data processing module is used to perform data cleaning, normalization and feature extraction based on the configuration diagram, and generate a data processing snapshot associated with the configuration snapshot; The training engine module is used to assemble the training process according to the configuration diagram and the data processing snapshot, receive parameter adjustment instructions from the visualization configuration module, update the adjustable parameters during the training process, record the correlation information between parameters, data and model according to the training rounds, and export the model package. The inference engine module is used to load the model package and associated data processing snapshots, perform parameterized configuration of multi-source data access according to the configuration diagram, and perform online inference to generate inference results.

2. The system according to claim 1, characterized in that, The provision of graphical orchestration operations and generation of configuration diagrams, and the performance of consistency verification and versioned storage of the configuration diagrams to form configuration snapshots, include: It receives node drags, connections, and parameter inputs from users in the visual interface, and solidifies the node types, connection relationships, and parameter sets into a configuration diagram. Based on the parameter templates and data processing flow templates carried by the algorithm entries in the algorithm library module, a description of the parameter constraints and dependencies of the algorithm nodes and data processing nodes in the configuration diagram is generated. A consistency check is performed on the configuration diagram, wherein the consistency check includes a matching check of node type and connection direction, a matching check of data form and sampling characteristics, a valid check of required parameters and their value range, and a check of the integrity of upstream and downstream dependencies. The verified configuration diagram is stored in a versioned manner, a corresponding configuration snapshot identifier is generated, and the association information with the algorithm entry version and the data processing flow template version is recorded to form the configuration snapshot.

3. The system according to claim 1, characterized in that, The provision of algorithm entries with a unified calling interface, which are selected and instantiated as algorithm nodes according to the configuration diagram, includes: Provides algorithm entry metadata and a unified calling interface, which is used to perform training, inference and evaluation; Based on the selection of algorithm nodes and parameter configuration in the configuration diagram, the corresponding algorithm entries are loaded from the algorithm library module, and an instantiated parameter set is generated by combining the parameter template, and a reference relationship is established with the data processing flow template indication; Perform a consistency check on the algorithm node before instantiation, and create an algorithm node instance after the check passes, and register the association information of the algorithm node identifier with the algorithm entry version, parameter template version and the data processing flow template version.

4. The system according to claim 1, characterized in that, The step of performing data cleaning, normalization, and feature extraction based on the configuration diagram to generate a data processing snapshot associated with the configuration snapshot includes: The data processing nodes and directed connections in the configuration diagram are analyzed to determine the operator sequence and parameter set used for data processing, and a reference relationship is established with the configuration snapshot. The input from industrial data sources is acquired and unified into an internal data representation, which includes data format, time identifier, and channel identifier. Data cleaning, normalization, and feature extraction are performed sequentially according to the operator sequence, and the consistency between the data form of each operator input and output and the input expectation of the algorithm node is verified during the execution process. The data processing snapshot is generated based on the operator sequence, parameter set, data form mapping relationship, and association information with the configuration snapshot and algorithm node.

5. The system according to claim 1, characterized in that, The assembly training process based on the configuration diagram and the data processing snapshot includes: The configuration diagram is analyzed to obtain the algorithm nodes, data sources, training parameters, and evaluation metric configurations of the training job, and a reference relationship is established with the data processing snapshot; Load the algorithm node and parameter template, combine the data processing snapshot to determine the form of training input and batch processing method, and initialize the training job and adjustable parameter whitelist; During the training iteration, the system receives parameter adjustment instructions from the visualization configuration module, updates the training parameters belonging to the whitelist online, and maintains the continuity of the training state.

6. The system according to claim 5, characterized in that, The process of updating adjustable parameters during training, recording the correlation information between parameters, data, and the model according to training rounds, and exporting the model package includes: In each training round, a training record is generated, and the parameter set, data subset identifier, model weight identifier and evaluation metric summary of the current round are stored in a fixed manner, and a reference relationship is established with the data processing snapshot and the configuration snapshot. When the export conditions are met, a model package is generated and a model identifier is assigned. The model package contains model topology, weights, and dependency information. Register the association information of the model package and algorithm node version, the data processing snapshot, and the configuration snapshot.

7. The system according to claim 1, characterized in that, The step of parameterizing the multi-source data access according to the configuration diagram and performing online inference to generate inference results includes: Analyze the nodes and parameters related to data access in the configuration diagram, determine the data source type, connection parameters and sampling or polling strategy, and establish the corresponding data input channel; The data received is preprocessed in the same way as during training according to the data processing snapshot to obtain inference input that meets the expectations of the algorithm node input; The inference input is organized according to the batch processing or timing window strategy set in the configuration diagram, and the algorithm node is called to perform online inference and generate the corresponding inference results.

8. The system according to claim 1, characterized in that, The system also includes: The model version management module is used to store the model package in a versioned manner, associate the model package with the corresponding data processing snapshot, provide effective version selection and version switching control, and issue the model identifier corresponding to the currently effective model package to the inference engine module.

9. The system according to claim 1, characterized in that, The system also includes: The rule configuration module is used to configure the output format and rules of the reasoning results according to the configuration diagram, generate output data and alarm commands, and provide the output data and alarm commands to the external industrial control system through the external interface.

10. A configurable artificial intelligence application method for industrial automation based on the system described in any one of claims 1 to 9, characterized in that, include: In the visualization configuration module, graphical arrangement is performed to generate a configuration diagram containing node, connection and parameter information. The configuration diagram is then subjected to consistency verification and versioned storage to form a configuration snapshot. Select algorithm entries from the algorithm library module according to the configuration diagram, generate instantiated parameter sets according to the parameter template, and create algorithm nodes; The data processing module parses the configuration diagram to determine the sequence of data processing operators, receives industrial data and sequentially performs data cleaning, normalization and feature extraction, and generates a data processing snapshot associated with the configuration snapshot. The training engine module assembles the training process based on the configuration diagram and data processing snapshot, loads the algorithm node and initializes the training parameters, updates the adjustable parameters online according to the parameter adjustment instructions, records the correlation information between parameters, data and model according to the training rounds and exports the model package. The inference engine module loads the model package and associated data processing snapshot, performs parameterized configuration of multi-source data access according to the configuration diagram, performs preprocessing on the accessed data according to the data processing snapshot, and calls the algorithm node to perform online inference to generate inference results.

Images