Unified data source interaction system and method for industrial HMI configuration

Abstract

The application provides a unified data source interaction system and method for industrial HMI configuration. It includes: a multi-source adaptation module for configuring connection parameters for multiple heterogeneous data sources in a unified data source service layer and generating data set definitions based on the configured data sources; a metadata persistence module for establishing a mapping relationship between data set identifiers and corresponding data sources and data standardization rules corresponding to the data sets; a component binding module for recording data request parameters and data update trigger methods associated with binding relationships; a data service execution module for reading data set definitions corresponding to data set identifiers from a metadata warehouse and obtaining raw data from corresponding data sources; and a data standardization module for returning unified format data results to visual components for visual rendering. The application can improve multi-source data integration efficiency, enhance data output consistency, and reduce configuration, change, and maintenance costs.

Description

Technical Field

[0001] This application relates to the fields of industrial automation control and industrial data visualization, and in particular to a unified data source interaction system and method for industrial HMI configuration. Background Technology

[0002] This application relates to the fields of industrial automation control and industrial data visualization, specifically to the development of industrial human-machine interface (HMI) configuration software and data interaction technology. In particular, it relates to systems and methods for accessing, abstracting, and interacting with multi-source heterogeneous data, such as databases, interface services, file data sources, and industrial databases, in industrial HMI configuration and web-based large-screen dashboard display scenarios. With the increasing demands for industrial site monitoring, production reports, and operational analysis, HMI configurations often need to simultaneously access relational database data, interface return data, Excel / CSV file data, and real-time, historical, and alarm data from industrial databases, continuously providing data to upper-level visualization components to complete chart displays and interactive linkages.

[0003] Existing solutions typically adapt access interfaces separately for each data source type, and during configuration development, data is converted one by one into the format required by each component before being bound to each visualization component. When the data source structure, fields, or access method changes, the interface, conversion rules, and multiple component binding relationships need to be adjusted simultaneously. Due to the lack of a unified adaptation layer for multi-source data, the lack of a standardized data model covering different data formats, and the coupling between the data source interface and component binding logic, there is a large amount of repetitive work in data integration and configuration, difficulty in unifying data standards across components, and high costs for adding new data sources or changing adaptations. This makes it difficult to meet the requirements of consistent access and continuous updates of multi-source data for web-based large screens. Summary of the Invention

[0004] In view of this, embodiments of this application provide a unified data source interaction system and method for industrial HMI configuration, in order to solve the problems of scattered multi-source heterogeneous data access and adaptation, inconsistent data models, and data interface and component binding and coupling in the prior art.

[0005] The first aspect of this application provides a unified data source interaction system for industrial HMI configuration, comprising: a multi-source adaptation module, used to configure connection parameters for multiple heterogeneous data sources in a unified data source service layer, and generate a dataset definition based on the configured data source, wherein the dataset definition includes a dataset identifier, parameter constraints, and an access description for obtaining data from the corresponding data source; a metadata persistence module, used to persistently store the connection parameter configuration and dataset definition in a metadata repository, and establish a mapping relationship between the dataset identifier and the corresponding data source, as well as data standardization rules corresponding to the dataset; a component binding module, used to establish a binding relationship between a visualization component and a dataset identifier in the industrial HMI configuration, and record the data request parameters and data update triggering methods associated with the binding relationship; a data service execution module, used to receive data requests containing a dataset identifier and data request parameters initiated by the visualization component through a unified data service interface during the runtime phase, read the dataset definition corresponding to the dataset identifier from the metadata repository, and schedule a data agent matching the data source type to obtain raw data from the corresponding data source based on the mapping relationship; and a data standardization module, used to clean and transform the raw data according to data standardization rules, generate a unified format data result, and return the unified format data result to the visualization component for visualization rendering.

[0006] The second aspect of this application provides a unified data source interaction method for industrial HMI configuration based on the system of the first aspect, comprising: configuring connection parameters for multiple heterogeneous data sources in a unified data source service layer, and generating a dataset definition based on the configured data source, wherein the dataset definition includes a dataset identifier, parameter constraints, and an access description for obtaining data from the corresponding data source; persistently storing the connection parameter configuration and dataset definition in a metadata repository, and establishing a mapping relationship between the dataset identifier and the corresponding data source, as well as data standardization rules corresponding to the dataset; establishing a binding relationship between the visualization component and the dataset identifier in the industrial HMI configuration, and recording the data request parameters and data update triggering methods associated with the binding relationship; during the runtime phase, receiving a data request initiated by the visualization component containing a dataset identifier and data request parameters through a unified data service interface, reading the dataset definition corresponding to the dataset identifier from the metadata repository, and scheduling a data agent matching the data source type to obtain raw data from the corresponding data source based on the mapping relationship; cleaning and transforming the raw data according to the data standardization rules to generate a unified format data result, and returning the unified format data result to the visualization component for visualization rendering.

[0007] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: The system employs a multi-source adaptation module to configure connection parameters for various heterogeneous data sources within a unified data source service layer. It generates dataset definitions based on these configurations, including dataset identifiers, parameter constraints, and access descriptions for retrieving data from the corresponding data source. A metadata persistence module persists the connection parameter configurations and dataset definitions to a metadata repository, establishing a mapping between dataset identifiers and corresponding data sources, as well as data standardization rules for each dataset. A component binding module binds visualization components to dataset identifiers in industrial HMI configurations, recording associated data request parameters and data update triggering methods. A data service execution module receives data requests from visualization components containing dataset identifiers and data request parameters via a unified data service interface during runtime. It reads the dataset definition corresponding to the dataset identifier from the metadata repository and schedules a data agent matching the data source type to retrieve raw data from the corresponding data source based on the mapping relationship. Finally, a data standardization module cleanses and transforms the raw data according to data standardization rules, generating a unified format data result, which is then returned to the visualization component for visualization rendering. This application can improve the efficiency of multi-source data integration, enhance data output consistency, and reduce configuration and change maintenance costs. 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 structure of the unified data source interaction system for industrial HMI configuration provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the intelligent chart configuration method for human-computer interface based on multimodal interaction provided in this application embodiment. 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] Current industrial HMI configurations that integrate multiple data sources and support web-based large-screen displays require first classifying the data sources and adapting their interfaces, then binding the corresponding data to the large-screen components one by one. Furthermore, different components require different data formats, and when the data source changes, the interface needs to be readjusted, the format converted, and the binding re-bound, resulting in low reusability.

[0012] The core reason for these problems lies in the failure to design a unified architecture that addresses the commonalities and characteristics of various data sources, as detailed below: Lack of a unified adaptation layer: The protocols of various data sources (such as SQL for databases, HTTP for APIs, and OPC UA for industrial libraries) and storage formats (such as .xls / .xlsx for Excel, .csv for CSV, and time-series formats for industrial libraries) vary greatly. Existing solutions do not provide one-stop adaptation capabilities and require overcoming technical barriers one by one.

[0013] The data model lacks standardization: the lack of a unified data format covering various data sources makes it impossible for Excel spreadsheet data, industrial database time-series data, and API unstructured data to be directly interoperable.

[0014] Interface and configuration coupling: The data source interface is directly linked to the binding logic of the visualization components. For example, after the database fields are changed, all visualization dashboard components need to be reconfigured, which increases the workload of the project implementation personnel.

[0015] To address the shortcomings of existing technologies, the most significant technical problem this application aims to solve is the low efficiency, poor consistency, insufficient scalability, and inability to guarantee real-time performance of data integration on web-based large-screen dashboards due to the lack of a unified adaptation, standardized model, and decoupled architecture for heterogeneous data from multiple sources such as databases, API interfaces, Excel files, CSV files, and industrial libraries in industrial HMI configuration.

[0016] In view of the problems existing in the prior art, this application provides a unified data source interaction system and method for industrial HMI configuration. The core idea of ​​this application is to introduce a unified data source service layer as a bridge between HMI configuration and various underlying data sources. This method simplifies the configuration development process by uniformly encapsulating, abstracting and managing heterogeneous data sources, and providing standardized data services to the upper layer in the form of "datasets".

[0017] This application belongs to the field of industrial automation control and industrial data visualization, specifically involving the development of industrial human-machine interface configuration software and data interaction technology. It covers methods for unified access, abstraction and interaction of various types and heterogeneous industrial data sources in industrial scenarios, aiming to simplify the configuration process of HMI applications and improve maintainability and scalability.

[0018] HMI stands for Human-Computer Interface, which is used to present raw data in industrial production and manufacturing in an easy-to-understand visual form such as graphics, charts, tables, and animations, and supports interactive operation through devices such as mouse, keyboard, and touch screen.

[0019] Data source: A data source refers to the location or carrier that generates and stores raw data. It is the source of data and includes databases, API interfaces, Excel files, CSV files, real-time data, historical data, alarm data, etc. in industrial databases, which are used to provide raw data.

[0020] Dataset: A dataset is a structured collection of data extracted or organized from a data source. It can be directly used for visualization purposes such as analysis, modeling, dashboards, and reports.

[0021] The following is a summary description of the components and functions of the unified data source interaction system for industrial HMI configuration of this application, with reference to embodiments. The unified data source interaction system for industrial HMI configuration of this application mainly includes the following functional modules: I. Multi-source adaptation module Unified configuration is performed in the unified data source service layer: Data source configuration: Configure connection parameters for each type of data source.

[0022] Database: Configuration type (MySQL / Oracle, etc.), connection URL, username, password, driver class.

[0023] API Interface: Configure endpoint URL, authentication method (API Key / OAuth, etc.), request headers, and default parameters.

[0024] File data source: configuration file path (local / network), file type (Excel / CSV), encoding format, and parsing rules.

[0025] Industrial database: Configure server address, collection tag points, sampling frequency, and historical data query parameters.

[0026] Dataset configuration: Create business datasets based on the configured data sources.

[0027] SQL Dataset: Write query statements, which can include parameterized queries.

[0028] API dataset: Configure request methods (GET / POST), path parameters, query parameters, and request body template.

[0029] File dataset: Defines the starting row, column mapping relationship, and data type conversion rules.

[0030] Real-time dataset: Configure the list of subscribed tags and the conditions for triggering data changes.

[0031] Strategy Configuration: Configure the caching strategy (TTL), update frequency, and data refresh conditions for the dataset.

[0032] II. Data Persistence Persistently store configuration information in a metadata repository, including the following: Data source connection information (encrypted storage of sensitive information); Dataset definition and its mapping relationship with the data source; Data transformation and standardization rules; Access control policy.

[0033] III. Standardized Binding of HMI Components In the HMI configuration development process, the steps developers take when binding data to visualization components are as follows: A. Select or enter a unique ID for the target dataset; B. Configure data binding parameters (such as query parameters and filtering conditions); C. Configure the data update trigger method (timed refresh / event-driven / real-time push).

[0034] IV. Implementation of Unified Data Services When the web-based dashboard is running, data requests are processed according to the following procedure: 1) Request reception: The dataset service engine receives data requests from the HMI component through the unified API endpoint. The request contains the dataset ID and necessary parameters.

[0035] 2) Request verification: Verify the validity of request permissions and parameters. For datasets that support caching, check if there is valid data in the cache.

[0036] 3) Data Acquisition: Query the data warehouse to obtain the complete definition of the dataset. Then, according to the data source type, schedule the corresponding data proxy component. The data proxy establishes a connection with the underlying data source and executes queries / requests. Standardize, clean, and transform the acquired raw data. Finally, return the processed standard JSON format data to the HMI component. For real-time data sources, establish a long connection or WebSocket push mechanism to ensure real-time updates of data changes.

[0037] The specific structure and functions of the unified data source interaction system for industrial HMI configuration 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 unified data source interaction system for industrial HMI configuration provided in an embodiment of this application, as shown below. Figure 1As shown, the system may specifically include the following modules: The multi-source adaptation module 101 is used to configure connection parameters for multiple heterogeneous data sources in the unified data source service layer, and generate a dataset definition based on the configured data source. The dataset definition includes a dataset identifier, parameter constraints, and an access description for obtaining data from the corresponding data source. The metadata persistence module 102 is used to persistently store the connection parameter configuration and dataset definition to the metadata repository, and to establish the mapping relationship between the dataset identifier and the corresponding data source, as well as the data standardization rules corresponding to the dataset. The component binding module 103 is used to establish a binding relationship between visualization components and dataset identifiers in industrial HMI configuration, and to record the data request parameters and data update triggering methods associated with the binding relationship; The data service execution module 104 is used to receive data requests initiated by the visualization component, which include dataset identifiers and data request parameters, through the unified data service interface during the runtime phase; read the dataset definition corresponding to the dataset identifier from the metadata repository; and schedule a data agent matching the data source type to obtain the original data from the corresponding data source based on the mapping relationship. The data standardization module 105 is used to clean and transform the raw data according to data standardization rules, generate data results in a unified format, and return the data results in a unified format to the visualization component for visualization rendering.

[0038] In some embodiments, the multi-source adaptation module is specifically used for: Receive data source configuration requests for different data source types, and generate corresponding data source connection descriptions based on the data source configuration requests; A dataset definition is created based on the data source connection description, and a dataset identifier is assigned to the dataset definition. The dataset definition includes parameter constraints associated with the dataset identifier, an access description for retrieving data from the corresponding data source, and an output field description corresponding to the access description. Define a data update strategy for the dataset, including cache duration and / or update trigger conditions, for subsequent data request processing based on the dataset identifier.

[0039] Specifically, the multi-source adaptation module first receives data source configuration requests for different data source types and generates corresponding data source connection descriptions based on these requests. The data source configuration request characterizes the data source type, connection location, and the set of basic parameters required for authentication or parsing. For relational database data source configuration requests, the request includes at least connection elements such as database type identifier, connection address, port, database name, username, and password. The multi-source adaptation module organizes these connection elements into a database connection description and records the driver identifier and connection string template used to establish a database session during runtime within the connection description.

[0040] For API interface type data source configuration requests, the data source configuration request must at least include the endpoint address, request method set, authentication method identifier, and default request header parameters. The multi-source adaptation module organizes the above content into an interface connection description, and records the reference positions of authentication parameters and the generation constraints of signature parameters in the connection description. For file type data source configuration requests, the data source configuration request must at least include parsing elements such as file location, file type identifier, character encoding, delimiter, or worksheet name. The multi-source adaptation module organizes the above content into a file connection description, and records the reference entries of file reading methods and parsing rules in the connection description.

[0041] For data source configuration requests of industrial database type, the data source configuration request includes at least the server address, namespace or project identifier, point set or tag directory, and sampling period or subscription period parameters. The multi-source adaptation module organizes the above content into an industrial database connection description, and records the channel parameters used for real-time subscription or historical query in the connection description. The above data source connection descriptions all store data source type, connection parameter set, and parameter validity information in a unified field structure, so that subsequent modules can complete data access scheduling based solely on the data source type and connection description.

[0042] Furthermore, after generating the data source connection description, the multi-source adaptation module creates a dataset definition based on the data source connection description and assigns a dataset identifier to the dataset definition. The dataset identifier is used to uniquely reference the corresponding dataset in the visualization component binding and runtime requests of the industrial HMI configuration. To ensure that the dataset definition can independently drive data acquisition and standardization processing during the runtime phase, in this embodiment, the dataset definition includes at least parameter constraints associated with the dataset identifier, an access description for acquiring data from the corresponding data source, and an output field description corresponding to the access description.

[0043] Parameter constraints are used to limit the set of data request parameters and their constraint rules that can be passed to the visualization component during runtime. In some examples, parameter constraints include at least the parameter name, parameter type, whether it is required, value range or enumeration set, and default value. When creating a dataset definition, the multi-source adaptation module establishes an association between parameter constraints and dataset identifiers, enabling the runtime to perform parameter validity checks based on these identifiers when receiving data requests containing dataset identifiers. Access descriptions are used to characterize the access methods and content for specific data sources.

[0044] In some examples, for database-type datasets, the access description includes a structured query statement description, along with parameter placeholders and field selection descriptions; for API-type datasets, the access description includes a request path template, path parameter locations, query parameter mappings, and a request body template description; for file-type datasets, the access description includes a read range description, starting row location, column mapping rules, and incremental parsing conditions; and for industrial database-type datasets, the access description includes a list of subscription points, data change triggering conditions, and sampling period parameters. The output field description characterizes the set of returned fields corresponding to the access description and their semantic scope. In some embodiments, the output field description includes at least the output field name, field type, field unit or precision, field source mapping information, and the field's hierarchical position in the uniformly formatted data result. Through the output field description, the multi-source adaptation module can provide a direct basis for subsequently establishing field mapping relationships and output structure constraints.

[0045] The following example illustrates the generation process of the dataset definition. In one example, engineers need to display the operating status and alarm count of a production line device on a large web-based screen. The device status is derived from real-time locations in an industrial database, and the alarm count is derived from an alarm record table in a relational database.

[0046] For real-time locations in the industrial database, the multi-source adaptation module receives data source configuration requests of industrial database type and generates industrial database connection descriptions; then it creates a dataset definition for the real-time subscription dataset, assigns a dataset identifier such as DS_RT_001 to it, defines optional production line identifier and equipment identifier parameters in the parameter constraints, records the subscription point list and sampling period in the access description, and records the status field, timestamp field and their data type and unit in the output field description.

[0047] For the alarm log table, the multi-source adaptation module receives a data source configuration request of the database type and generates a database connection description; then it creates a dataset definition for the database query dataset, assigns a dataset identifier such as DS_SQL_002, defines the start and end time and device identifier parameters in the parameter constraints, records the structured query statement description and parameter placeholders in the access description, and records the output field scope such as alarm level field, count field, and time window field in the output field description.

[0048] Using the above method, the web-based dashboard component only needs to reference DS_RT_001 or DS_SQL_002 to obtain real-time status data and alarm count data respectively, without needing to worry about the connection details and field structure differences of the underlying data source on the component side.

[0049] In this embodiment, the multi-source adaptation module also defines and configures a data update strategy for the dataset. The data update strategy instructs the data service execution module during runtime on the refresh frequency, caching behavior, and triggering conditions for the dataset, thereby achieving a consistent data service call pattern under different data source characteristics. The data update strategy includes cache duration and / or update triggering conditions. For example, the cache duration specifies the effective time window for data results in a uniform format in the cache, applicable to non-real-time datasets such as database query datasets, interface request datasets, and file parsing datasets. The multi-source adaptation module associates the cache duration with the dataset identifier, enabling the runtime phase to generate a cache key based on the dataset identifier and data request parameters and determine whether the cache has been hit.

[0050] Update trigger conditions specify when to trigger data re-acquisition or push updates, applicable to real-time subscribed datasets and datasets requiring event-driven refresh. In some examples, update trigger conditions include one or more of the following: timed refresh cycle, parameter change trigger condition, data change trigger threshold, or alarm trigger condition; for example, for a real-time point dataset in an industrial database, the update trigger condition can be set to trigger a push when the point value changes beyond a preset threshold or an alarm event occurs; for an Excel / CSV file dataset, the update trigger condition can be set to trigger re-parsing when the file update time changes or to trigger incremental parsing at a preset cycle. Through the above strategy configuration, the system can maintain a unified dataset access method while ensuring that different data sources exhibit data update behavior that matches their characteristics during runtime.

[0051] This embodiment configures a multi-source adaptation module within the unified data source service layer, unifying the configuration of connection parameters, dataset definition generation, and data update strategy configuration of heterogeneous multi-source data sources into a configuration chain centered on the dataset identifier. This enables subsequent data request processing to automatically assemble access descriptions, output field descriptions, and update strategies based on the dataset identifier, reducing repetitive workload in multi-source access configuration and providing a consistent configuration foundation for unified output and component binding across data sources.

[0052] In some embodiments, a dataset definition includes one or more dataset type identifiers, which are used to indicate the query or subscription method corresponding to the dataset definition. The dataset type identifier includes one or more of the following: database query dataset, interface request dataset, file parsing dataset, and real-time subscription dataset. The access description includes a query statement description, request template description, parsing rule description, or subscription point description that matches the dataset type identifier.

[0053] Specifically, the setting of dataset type identifiers follows the abstract principle of "data acquisition mechanism as the main thread," rather than simply distinguishing them by data source name. Specifically, database query datasets indicate data acquisition from relational databases using structured query statements; interface request datasets indicate data acquisition from interface services using HTTP requests; file parsing datasets indicate data acquisition from Excel or CSV files using file reading and parsing; and real-time subscription datasets indicate acquisition of at least one type of data—real-time, historical, or alarm data—from industrial databases via subscription or long-lived connections. When creating dataset definitions, the multi-source adaptation module writes corresponding dataset type identifiers to the dataset definitions based on the access channel characteristics and data update requirements of the target data source, and stores the dataset type identifiers in association with the dataset identifiers. This serves as the basis for the data service execution module to schedule data proxies and parse access descriptions during runtime.

[0054] In some examples, the access description includes a query statement description, request template description, parsing rule description, or subscription point description that matches the dataset type identifier. To ensure the access description is executable, this embodiment designs the access description as a "parameterizable access template" and establishes a correspondence with the parameter constraints in the dataset definition. This allows the data request parameters passed from the visualization component to the parameter positions in the access description during runtime, thereby generating the final executable query, request, parsing, or subscription configuration.

[0055] In the implementation of database query datasets, the access description includes a query statement description. The query statement description characterizes the query statement template and parameter placeholder relationships required to retrieve data from the relational database. In some embodiments, the query statement description includes at least the query statement text, parameter placeholder names, the correspondence between parameter placeholders and parameter constraints in the dataset definition, and the correspondence between output fields and query result columns. During the configuration phase, the multi-source adaptation module allows engineers to select a target data table or view and fill in query conditions in the dataset configuration entry, or directly fill in the query statement template. Simultaneously, engineers can define parameters such as time range, equipment identifier, and production line identifier in the parameter constraints and establish a correspondence between them and the placeholders in the query statement description. During the runtime phase, the data service execution module receives a data request containing the dataset identifier and data request parameters, fills the data request parameters into the query statement description to form an executable query request, and then hands it over to the database agent to establish a connection and execute the query to obtain the original query results.

[0056] In the implementation of the interface request dataset, the access description includes a request template description. The request template description characterizes the organization of the endpoint path, request method, request headers, path parameters, query parameters, and request body fields of the interface service. In some examples, the request template description may include an endpoint path template, request method identifier, authentication parameter referencing method, request header key-value set, parameter mapping rules, and response parsing entry point. During the configuration phase, the multi-source adaptation module allows engineers to configure default request headers for the same interface service and define filtering conditions or pagination parameters that can be passed in by the visualization component within the parameter constraints defined in the dataset; simultaneously, it establishes a mapping relationship between these parameters and the path parameter positions or query parameter positions in the request template description. During the runtime phase, the interface proxy constructs a request message based on the request template description, fills in the data request parameters with the actual request parameters, completes the interface call, and obtains the raw response data.

[0057] Furthermore, in the implementation of the file parsing dataset, the access description includes a parsing rule description. The parsing rule description characterizes the reading range, field location, and type parsing method for the Excel or CSV file. In some examples, the parsing rule description may include file location references, worksheet names or delimiter parameters, starting row positions, mapping rules between column fields and output fields, and basic constraints for type conversion. During the configuration phase, the multi-source adaptation module allows engineers to specify the starting row, column names, or column numbers of the file, define the correspondence between each column and the field names in the output field description, and define type parsing rules for strings, integers, floating-point numbers, date and time, etc. During the runtime phase, the file agent reads and parses the file according to the parsing rule description, obtains the raw tabular data, and outputs it as raw data to the subsequent standardization conversion process.

[0058] Furthermore, in the implementation of the real-time subscription dataset, the access description includes a subscription point description. The subscription point description characterizes the set of tag points to be subscribed to in the industrial database, as well as key parameters for subscription and sampling. In some embodiments, the subscription point description includes at least a list of point identifiers, point grouping information, sampling period or subscription period parameters, data change triggering conditions, and session persistence parameters. During the configuration phase, the multi-source adaptation module allows engineers to select points such as equipment status, process parameters, energy consumption metering, and alarm events from the tag directory, and configure sampling periods or change triggering thresholds for the selected points. For alarm-type points, the subscription point description may also include extraction rules for alarm level and event time fields. During the operation phase, the real-time data agent establishes a long connection or push channel with the industrial database based on the subscription point description, continuously receives incremental raw data of point changes, and triggers uploads according to data change triggering conditions when needed.

[0059] This embodiment sets a dataset type identifier in the dataset definition and configures the access description to match the dataset type identifier. This enables the runtime phase to determine the data acquisition method and schedule the corresponding data agent based solely on the dataset identifier, reducing the differentiated processing of upper-layer configuration configurations when different data sources are accessed. At the same time, since the access description corresponds to parameter constraints in a parameterizable template manner, the component side only needs to pass in the data request parameters to drive the query or subscription execution, thereby improving the dataset reuse capability and configuration efficiency, and reducing the maintenance costs caused by differences in data source types.

[0060] In some embodiments, establishing a mapping relationship between dataset identifiers and corresponding data sources, as well as data standardization rules corresponding to the datasets, includes: The dataset identifier is associated with and stored in the dataset definition with the data source type, data source connection description and access description, so as to generate a mapping relationship for locating the target data source and selecting a data agent that matches the data source type during the runtime phase; Based on the output field descriptions in the dataset definition, establish field mapping relationships, and combine data source type configuration with data type conversion rules and output structure constraints to generate data standardization rules associated with the dataset identifier; The mapping relationships and data standardization rules are written into the metadata repository and stored in association with the dataset identifier, so that the data service execution module can call them when it receives a data request containing the dataset identifier.

[0061] Specifically, the dataset identifier is first associated with and stored in relation to the data source type, data source connection description, and access description in the dataset definition. This generates a mapping relationship used during runtime to locate the target data source and select a data proxy that matches the data source type. After receiving the dataset definition submitted by the multi-source adaptation module, the metadata persistence module extracts the dataset identifier for each dataset definition and parses it to obtain the data source type field, data source connection description, and access description.

[0062] The data source type field is used to distinguish one or more of relational databases, interface services, file data sources, and industrial databases; the data source connection description is used to provide the set of basic parameters required to establish a connection, such as database connection address and authentication parameters, interface endpoint and authentication parameters, file location and parsing entry point, industrial database server address and site directory, etc.; the access description is used to provide an executable access template for obtaining data, such as query statement description, request template description, parsing rule description, or subscription site description.

[0063] The metadata persistence module establishes a one-to-one correspondence between the above three types of information and the dataset identifier, and writes the data agent selection identifier or data agent type identifier into the association record. This enables the data service execution module to directly determine the database agent, interface agent, file agent or real-time data agent to be called when reading the association record during the runtime phase, thereby forming the executability of the mapping relationship.

[0064] In some examples, to improve the stability of the mapping relationship under data source changes, the metadata persistence module distinguishes between "data source connection description identifier" and "access description identifier" in the mapping relationship. The data source connection description identifier references the connection configuration version of the same data source, while the access description identifier references the access template version of the same dataset. When the database address or interface authentication parameters change, only the connection parameters corresponding to the data source connection description identifier need to be updated, without changing the dataset identifier and access description identifier, thus maintaining the visualization component's reference to the dataset identifier.

[0065] Furthermore, based on the output field descriptions in the dataset definition, field mapping relationships are established, and data type conversion rules and output structure constraints are configured according to the data source type to generate data standardization rules associated with the dataset identifier. These standardization rules are used to convert raw data returned from different data sources into data results in a unified format, avoiding inconsistencies in the interpretation of the same metric across different components.

[0066] In this embodiment, the metadata persistence module uses the output field description as the entry information for standardization rules. The output field description declares the set of fields and semantic definitions of the fields to be output by the dataset, such as field name, field type, unit or precision, and the position of the field in the result structure. The metadata persistence module establishes field mapping relationships based on the output field descriptions, enabling the field mapping relationships to locate the original data fields to the unified output fields.

[0067] For example, when the data source is a relational database, the field mapping relationship maps the column names of the query results to the output field names; when the data source is an interface service, the field mapping relationship maps the path field in the response body to the output field name; when the data source is a file data source, the field mapping relationship maps the column header or column number to the output field name; when the data source is an industrial database, the field mapping relationship maps the location identifier to the output field name, and can also map the location sampling time to a unified timestamp field.

[0068] Meanwhile, the metadata persistence module configures data type conversion rules based on the data source type. In some embodiments, data type conversion rules include at least one or more of the following: character encoding conversion rules, numeric type conversion rules, date and time format conversion rules, and Boolean or enumeration value normalization rules. Taking date and time as an example, database queries may return timestamps or date strings, interface responses may return ISO8601 format strings, file parsing may return Excel serialized dates, and industrial databases may return sampling time and millisecond timestamps. The metadata persistence module uniformly configures the "time field" to the target time format in the data type conversion rules, thereby ensuring the comparability of the time field in data results with a unified format. Taking numeric types as an example, industrial locations may return string-type numeric values ​​or text with units, file data may contain null values ​​or abnormal characters, and interface responses may contain a mixture of floating-point and integer values. By defining the target type and exception handling methods, the data type conversion rules enable the subsequent data standardization module to complete type conversion and cleaning according to the same rules.

[0069] Furthermore, the metadata persistence module configures output structure constraints based on data source type to ensure a uniform data result structure. In some examples, output structure constraints include at least the organization format of the result data, field hierarchy constraints, and rules for arranging multiple records or time series points. For database query datasets and file parsing datasets, output structure constraints can define the result as a set of records and constrain the order or necessity of fields within the records. For real-time subscription datasets, output structure constraints can define the result as a set of time series points with timestamps and constrain the existence of time, location, and quality marker fields. For alarm datasets, output structure constraints can define the result as a set of event records and constrain the output positions of the event time, alarm level, and object identifier fields. Through output structure constraints, the data standardization module can generate consistent, uniformly formatted data results during runtime, enabling different visualization components to parse and render data in the same way.

[0070] In some examples, after generating the mapping relationships and data standardization rules, the metadata persistence module writes them into the metadata repository and stores them in association with the dataset identifier, so that the data service execution module can call them when it receives a data request containing the dataset identifier. To ensure rapid assembly during the runtime phase, this embodiment indexes the mapping relationships and data standardization rules using the dataset identifier as the primary key and saves version identifiers and update time information in the metadata repository. During the runtime phase, after receiving a data request containing the dataset identifier, the data service execution module first reads the mapping relationship through the dataset identifier to determine the data source type, data source connection description, access description, and select a matching data proxy; then, it reads the data standardization rules through the dataset identifier and sends the field mapping relationships, data type conversion rules, and output structure constraints to the data standardization module, realizing integrated execution of data retrieval and conversion.

[0071] This embodiment establishes mapping relationships and data standardization rules in the metadata repository with dataset identifiers as the core, enabling the target data source to be quickly located and the matching data agent to be automatically selected during the runtime phase. At the same time, the raw data returned by different data sources are unified into a consistent data result format according to field mapping, type conversion and structural constraints, thereby improving the assembly efficiency of multi-source data services and cross-component data consistency, and reducing the maintenance workload caused by data source changes and field adjustments.

[0072] In some embodiments, the component binding module is specifically used for: In the configuration interface, select or enter a dataset identifier for the target visualization component, and generate a binding record corresponding to the visualization component and the dataset identifier; Configure the data request parameters corresponding to the dataset identifier in the binding record. The data request parameters include one or more of the query parameters, filter conditions or path parameters, and are used by the data service execution module to generate a data request containing the dataset identifier and data request parameters during the runtime phase. Configure the data update triggering method in the binding record. The data update triggering method includes at least one or more of the following: timed refresh, event-driven, or real-time push. Among them, event-driven includes triggering updates based on changes in data request parameters or changes in data from the data source. Binding records are written to the metadata repository or configuration configuration file and stored in association with the visualization component identifier, so that during the runtime phase, the visualization component can be driven to request and receive data results in a unified format based on the binding records.

[0073] Specifically, the component binding module first selects or inputs a dataset identifier for the target visualization component in the configuration interface, and then generates a binding record corresponding to the visualization component and the dataset identifier. The configuration interface can be provided by industrial HMI configuration software, displaying a list of selectable dataset identifiers in the component properties panel or data binding panel. This list can be generated from published dataset definitions in the metadata repository. After selecting the target visualization component, the implementation personnel determine the dataset identifier to be bound to the component through drop-down selection or manual input. The component binding module then generates a binding record accordingly, writing the correspondence between the visualization component identifier and the dataset identifier into the binding record.

[0074] To ensure that the visualization component can directly locate its bound dataset based on the binding record during the runtime phase, the binding record in this embodiment includes at least a binding record identifier, a visualization component identifier, a dataset identifier, and binding relationship status information. The binding relationship status information is used to indicate whether the binding record is effective and whether runtime changes are allowed.

[0075] In some examples, the component binding module supports configuration methods of "one component, multiple datasets" or "multiple components, same dataset" when generating binding records. This adapts to scenarios in complex dashboards where the same component needs to be associated with multiple sets of metrics or the same dataset needs to be reused by multiple components. For the "one component, multiple datasets" scenario, the component binding module creates multiple binding records for the same visualization component identifier, or maintains a set of dataset identifiers in the same binding record, and configures independent data request parameters and data update triggering methods for each dataset identifier. For the "multiple components, same dataset" scenario, the component binding module generates binding records separately for different visualization component identifiers, but all reference the same dataset identifier, thus ensuring consistent data interpretation when multiple components display the same metric.

[0076] In this embodiment, the component binding module further configures data request parameters corresponding to the dataset identifier in the binding record. The data request parameters are used to represent one or more of the query parameters, filter conditions, or path parameters passed in by the visualization component during the runtime phase, and are used by the data service execution module to generate a data request containing the dataset identifier and data request parameters.

[0077] To ensure that the data request parameters are consistent with the parameter constraints in the dataset definition, the component binding module in this embodiment performs parameter name matching and type validation on the data request parameters during the configuration phase. That is, it reads the parameter constraints defined by the dataset from the metadata repository according to the bound dataset identifier, verifies whether the parameter name configured in the binding record exists in the parameter constraint set, and verifies whether the parameter value type and value range meet the parameter constraints.

[0078] For parameters that can be dynamically input during runtime, the component binding module saves parameter placeholder information and default values ​​in the binding record; for fixed parameters, the component binding module saves parameter constant values ​​in the binding record; for parameters generated by component interaction, the component binding module saves parameter source identifiers in the binding record to indicate that the parameter was generated by user interaction events, Kanban global filter conditions, or component linkage conditions.

[0079] The following example illustrates how to configure data request parameters. In one example, the dashboard includes three components: "Equipment Status List," "Alarm Trend Chart," and "Production Line Output Bar Chart." The dataset bound to the alarm trend chart supports time range parameters and alarm level filter parameters. After selecting a dataset identifier for the alarm trend chart in the configuration interface, the implementation personnel configure the data request parameters as startTime, endTime, and alarmLevelFilter in the binding record. They set startTime and endTime to dynamic parameters generated by the time selector at the top of the dashboard, and set alarmLevelFilter to the default value of 2, allowing users to adjust it during component interaction. During operation, when the user selects a new time range in the time selector or switches alarm levels on the alarm trend chart, the component generates the corresponding data request parameters based on the parameter source identifier in the binding record and triggers the data request.

[0080] In this embodiment, the component binding module also configures the data update triggering method in the binding record. The data update triggering method includes at least one or more of timed refresh, event-driven, or real-time push. Timed refresh instructs the component to initiate a data request to the data service execution module at a preset period; event-driven instructs the triggering of a data request when specific event conditions are met; real-time push instructs the data service execution module or data agent to actively push data update results to the component. Event-driven instructions include triggering updates based on changes in data request parameters or changes in data from the data source.

[0081] In some examples, updates triggered by changes in data request parameters are used to handle changes in data request parameters caused by changes in user filter conditions, linked conditions, or pagination conditions; the component binding module configures trigger rules for each type of parameter change event in the binding record, such as triggering a refresh immediately when filter parameters change, and updating only the current page data when pagination parameters change.

[0082] Data change-triggered updates are used to handle refreshes triggered when data changes occur on the data source side, such as the addition of alarm records to database tables, new data versions returned by interface services, changes in file update times, or changes in industrial database locations. The component binding module can record the corresponding data change trigger condition reference in the binding record, enabling the trigger condition to be executed in conjunction with the data update strategy defined in the dataset during the runtime phase.

[0083] Furthermore, the component binding module supports configuring combined triggering methods for the same bound record. For example, for a production line output bar chart, a timed refresh cycle of 60 seconds can be configured, while an event-driven rule can be configured to trigger a refresh immediately when the user switches the production line filter conditions. For a real-time equipment status component, a real-time push method can be configured, allowing it to receive incremental data results of point changes via a long connection, and degrading to a timed refresh method when the network is interrupted or push is unavailable. The component binding module associates and stores the above triggering methods with the bound records, thereby providing a triggering basis for the data service execution module during the runtime phase.

[0084] This embodiment uses a component binding module with a dataset identifier as the unified binding object to establish binding records for visualization components and configure data request parameters and data update triggering methods within them. This transforms the data binding on the component side from configuration oriented towards the data source interface and field structure to configuration oriented towards the dataset identifier. At the same time, through the validation of parameter constraints and the structured recording of triggering methods, the runtime phase can automatically generate data requests based on the binding records and select update methods such as timed refresh, event-driven, or real-time push. This reduces repetitive configuration work and lowers the component reconfiguration cost when the data source changes, thereby improving the consistency and maintainability of data access for large screen components.

[0085] In some embodiments, the data service execution module is specifically used for: The unified data service interface receives data requests from visualization components, which include dataset identifiers and data request parameters. It performs permission verification on the data request based on the access control policy associated with the dataset identifier in the metadata repository, and performs validity verification on the data request parameters based on the parameter constraints in the dataset definition. Read the dataset definition corresponding to the dataset identifier and the mapping relationship associated with the dataset identifier from the metadata repository; determine the data source type and data source connection description based on the mapping relationship; select the data agent that matches the data source type based on the data source type; and read the data update strategy associated with the dataset identifier. The access description and data request parameters are passed to the data broker, which then establishes a connection with the corresponding data source based on the data source connection description and performs a data acquisition operation that matches the access description to obtain the raw data.

[0086] Specifically, the data service execution module first receives a data request from the visualization component, containing a dataset identifier and data request parameters, through the unified data service interface. It then performs permission verification on the data request based on the access control policy associated with the dataset identifier in the metadata repository, and performs validity checks on the data request parameters based on the parameter constraints in the dataset definition. In some implementations, the unified data service interface uses a unified request entry path and a unified request structure, including at least a dataset identifier field and parameter fields. At runtime, the visualization component writes the dataset identifier it is bound to into the request based on the binding record, and organizes the query parameters, filter conditions, or path parameters configured in the binding record into data request parameters. Upon receiving the request, the data service execution module first performs an existence check on the dataset identifier, i.e., queries the metadata repository to see if a corresponding dataset definition exists; after confirming the dataset identifier is valid, it invokes the access control policy to perform permission verification.

[0087] In some examples, access control policies are established using dataset identifiers as indexes to limit the access subjects and access scope. Access subjects can be represented by user identity, application identifier, dashboard page identifier, or client token identifier. The data service execution module parses the access subject information on the unified data service interface side, such as parsing user session tokens or application authentication information, and uses the access subject information and dataset identifier together for permission verification. After successful permission verification, the data service execution module then performs validity checks on the data request parameters based on the parameter constraints in the dataset definition. Parameter constraints at least include parameter name, parameter type, whether it is required, and the range or enumeration set of values.

[0088] The data service execution module checks the data request parameters against parameter constraints to ensure that required parameters are missing, undefined parameters exist, parameter value types match, and parameter values ​​do not exceed the allowed range. This avoids the risk of abnormal access to the data source or data leakage caused by illegal parameters. In some embodiments, when the verification fails, the data service execution module generates information including error codes, error fields, and constraint hints and returns it to the visualization component, enabling the component to indicate parameter configuration errors or insufficient permissions on the interface.

[0089] Furthermore, after completing permission verification and parameter validation, the data service execution module reads the dataset definition corresponding to the dataset identifier and the mapping relationship associated with the dataset identifier from the metadata repository, determines the data source type and data source connection description based on the mapping relationship, selects the data agent matching the data source type based on the data source type, and reads the data update strategy associated with the dataset identifier.

[0090] In some examples, the data service execution module reads the dataset definition using the dataset identifier as the primary key, parsing it to obtain the access description, output field description, and data source type. Simultaneously, it reads the mapping relationship to obtain a reference to the data source connection description or a specific set of connection parameters. The data service execution module selects a data proxy based on the data source type. For example, it selects a database proxy when the data source type indicates a relational database, an interface proxy when the data source type indicates an interface service, a file proxy when the data source type indicates a file data source, and a real-time data proxy when the data source type indicates an industrial database. The data update strategy is used to subsequently determine whether to enable caching and whether to adopt a scheduled refresh, event-driven, or real-time push execution mode. The data update strategy includes at least one or more of the following: cache duration and update trigger conditions. After reading the data update strategy, the data service execution module writes it into the execution context of this request for subsequent cache judgment and trigger method processing.

[0091] Furthermore, after reading the data update policy, the data service execution module first determines the caching conditions. When the data update policy indicates support for caching and the cache duration is greater than 0, the data service execution module generates a cache key based on the dataset identifier and data request parameters, and queries the cache storage to see if there is a valid data result corresponding to the cache key. If a valid data result exists, the cached data result in a uniform format is directly returned to the visualization component, thereby reducing repeated access to the underlying data source. If no valid cache exists or the cache has expired, the data broker data retrieval process begins. In other embodiments, when the data update policy indicates real-time push or the trigger condition is data change, the data service execution module marks this request as a subscription request and subsequently establishes a continuous session with the data broker to receive incremental raw data or incremental result data.

[0092] In this embodiment, the data service execution module passes the access description and data request parameters to the data proxy. The data proxy then establishes a connection with the corresponding data source based on the data source connection description and executes a data acquisition operation matching the access description to obtain the raw data. In this embodiment, the data proxy is a set of pluggable proxy components that expose a unified execution entry point externally, while internally implementing connection establishment and access operations according to differences in data source type.

[0093] The data service execution module combines the access description and data request parameters into an executable request context. The access description provides the access template, and the data request parameters provide the actual parameter values. During execution, the data agent first establishes a connection based on the data source connection description. For example, a database agent establishes a database session, an interface agent establishes a request session and loads authentication parameters, a file agent locates the file and performs file reading, and a real-time data agent establishes a long-lived connection or push channel with the industrial database.

[0094] Subsequently, the data broker performs matching data retrieval operations based on the access description: For database query datasets, the database broker fills the data request parameters into the query statement description and executes the query to obtain the raw query results; for interface request datasets, the interface broker fills the data request parameters into the request template description and initiates an interface request to obtain the raw response data; for file parsing datasets, the file broker parses the files according to the parsing rules to obtain the raw tabular data; for real-time subscription datasets, the real-time data broker subscribes to the subscription points according to the subscription point description and receives point changes to form incremental raw data. The data broker returns the obtained raw data to the data service execution module or directly outputs it to the data standardization module for subsequent cleaning, transformation, and unified format packaging processes.

[0095] In this embodiment, the data service execution module receives data requests through a unified data service interface during the runtime phase. It completes permission verification and parameter validation based on access control policies and parameter constraints. Then, it assembles dataset definitions, mapping relationships, and data update policies from the metadata repository to automatically select data proxies and drive them to perform matching data acquisition operations. This allows the visualization components to complete cross-data source data access without being aware of the differences in the underlying data sources. At the same time, through the strategic assembly of caching and push modes, it reduces redundant data retrieval and supports real-time data updates, thereby improving the execution efficiency and operational controllability of the web-based large-screen data service.

[0096] In some embodiments, the data service execution module is further configured to generate a cache key for the dataset identifier and data request parameters when the data update strategy indicates that caching is supported, and perform a cache hit determination on the data result in a unified format based on the cache key and a preset cache duration. If a valid cache is hit, the data result in a unified format is returned directly, and if a valid cache is not hit, the data agent is triggered to obtain the original data.

[0097] Specifically, the data update strategy is defined and configured for the dataset by the multi-source adaptation module during the configuration phase, and persisted to the metadata repository along with the dataset identifier. The data update strategy includes at least one or more of the following: cache duration and update trigger conditions. After the data service execution module reads the data update strategy associated with the dataset identifier from the metadata repository during the runtime phase, it first determines whether the dataset supports caching.

[0098] In some examples, the criteria for determining "support caching" include: the cache enable flag is enabled in the data update strategy, the cache duration is greater than 0, and the dataset type is not a real-time subscription dataset or a mode that does not require real-time push. For database query datasets, interface request datasets, and file parsing datasets, caching is usually enabled. For real-time subscription datasets, caching is usually disabled or only a short-term cache is enabled for the most recent snapshot to avoid affecting real-time performance.

[0099] Furthermore, after confirming caching support, the data service execution module generates a cache key for the dataset identifier and data request parameters. The cache key uniquely identifies the result instance of the same dataset under the same parameter combination, thus avoiding cache conflicts between different components or different filtering conditions. In this embodiment, cache key generation includes at least the following elements: dataset identifier, normalized representation of data request parameters, and optional version or permission domain information. The normalized representation of data request parameters is used to resolve the inconsistency of cache keys caused by different parameter orders but identical semantics.

[0100] In some examples, the data service execution module sorts data request parameters by name before concatenating them, or encodes and concatenates parameter names and values ​​according to fixed rules to form a deterministic parameter summary. When data request parameters include a time range, the time range can be normalized according to a unified format and written to the cache key. When data request parameters include a list or set, the set elements can be sorted and written to the cache key. Optionally, the data service execution module also writes the dataset definition version identifier to the cache key, so that a new cache key can be naturally formed when the access description or standardization rules are updated, thereby avoiding the misuse of cached results generated under the old rules. Optionally, the data service execution module also writes the permission domain identifier to the cache key to distinguish the differences in visible fields or visible ranges that may exist between different access subjects under the same dataset identifier, avoiding unauthorized reuse of cached results.

[0101] In some examples, the data service execution module performs cache hit determination on uniformly formatted data results based on the cache key and a preset cache duration. The hit determination includes at least two steps: first, an existence determination, which checks if a cache entry corresponding to the cache key exists in the cache storage; second, a validity determination, which checks if the interval between the cache entry's generation time and the current time is less than the preset cache duration. In some embodiments, the cache entry at least includes a cache key, uniformly formatted data results, a generation timestamp, and data update policy snapshot information associated with the dataset identifier. After reading the cache entry, the data service execution module calculates the validity period using the generation timestamp and the preset cache duration, or directly determines whether it has expired using the cache storage's expiration time field. If a valid cache hit is determined, the data service execution module no longer triggers the data broker to access the underlying data source, but instead directly returns the uniformly formatted data results from the cache entry to the visualization component, and records the hit event for runtime monitoring and capacity assessment when necessary.

[0102] In some examples, if a valid cache miss is detected, the data service execution module triggers a data broker to retrieve the raw data. In this embodiment, triggering the retrieval includes assembling the access description and data request parameters and invoking the matching data broker to perform the data retrieval operation. After the data broker returns the raw data, the data service execution module submits the raw data to the data standardization module, which performs cleaning and transformation according to the data standardization rules associated with the dataset identifier to generate a data result in a unified format. Subsequently, the data service execution module writes the unified format data result into the cache storage, using the cache key as an index and writing the generation timestamp or expiration time, while simultaneously returning the unified format data result to the visualization component.

[0103] To ensure cache consistency, in some examples, when the same cache key experiences concurrent misses within a short period of time, the data service execution module sets a mutual exclusion flag or a request merging flag for that cache key. This ensures that only one data proxy fetch and standardization transformation is executed within the same time window, while other concurrent requests wait for the results to be written to the cache before directly reading the cached results. This avoids instantaneous amplification of access to the underlying data source.

[0104] This embodiment, through the data service execution module, generates a cache key using the dataset identifier and data request parameters when the data update strategy indicates support for caching. It then performs a hit determination based on the cache key and a preset cache duration for data results in a unified format. This allows multiple components accessing the same dataset under the same parameter conditions to reuse data results in a unified format, reducing repeated connections and queries to the underlying data source. Simultaneously, by retrieving data when a miss occurs, standardizing and backfilling the cache link, and controlling concurrent request merging, it reduces load fluctuations in high-frequency access scenarios. Thus, while ensuring controllable data refresh, it improves the data service throughput of the web-based large screen and reduces operational pressure.

[0105] In some embodiments, when the dataset type identifier indicates a real-time subscription dataset, the data service execution module controls the data broker to establish a long connection or WebSocket push channel to receive data change events. The data standardization module performs cleaning and transformation on the received incremental raw data and pushes the incremental data results in a unified format to the visualization component according to the update triggering method corresponding to the bound record.

[0106] Specifically, in the configuration phase of real-time subscription datasets, the multi-source adaptation module generates a dataset definition that includes dataset identifiers, dataset type identifiers, and descriptions of subscription points, and stores it in the metadata repository in association with mapping relationships, data standardization rules, and data update strategies.

[0107] The subscription point description includes at least a list of point identifiers, sampling period or subscription period parameters, data change triggering conditions, and session persistence parameters. During runtime, after receiving a subscription-type data request initiated by the visualization component based on bound records, the data service execution module first performs permission verification and parameter validation. Then, it reads the dataset definition from the metadata repository, parses it to obtain the dataset type identifier as a real-time subscription dataset, and reads the subscription point description and the data update strategy associated with the dataset identifier. If the data update strategy indicates a real-time push mode or the update triggering condition is data change triggering, the data service execution module establishes this request as a subscription session and enters the long connection or push channel establishment process.

[0108] In some examples, the data service execution module controls the data broker to establish persistent connections or WebSocket push channels to receive data change events. The persistent connection can be a continuous session between the data broker and the industrial database, or a continuous session between the data service execution module and the visualization component; the WebSocket push channel is typically used by the data service execution module to push services to web-based components. In this embodiment, the data broker is responsible for establishing a continuous session with the industrial database and receiving data change events, while the data service execution module is responsible for maintaining the push channel with the visualization component and pushing data results according to the bound records. Specifically, the data service execution module passes the subscription point description and data request parameters to the real-time data broker. The real-time data broker establishes a connection with the industrial database based on the data source connection description and submits the subscription point list and trigger conditions to the industrial database after the connection is established, causing the industrial database to push data change events to the real-time data broker when point values ​​change or alarm events occur. After receiving the data change event, the real-time data broker sends the incremental raw data carried in the event, such as the point value, event time, quality marker, or alarm attributes, to the data standardization module or to the data service execution module and then forwards it to the data standardization module.

[0109] In some examples, to reduce resource consumption in the push process, the data service execution module manages subscription sessions by merging them. When multiple visualization components have binding records referencing the same real-time subscription dataset identifier and have consistent data request parameters, the data service execution module creates only one subscription session corresponding to the industrial database and maintains multiple component subscriber lists on the push side. After the real-time data broker receives a data change event, the data service execution module can distribute the same incremental result to multiple components. If different components have different data request parameters under the same dataset identifier, such as different device identifiers or different production line identifiers, the data service execution module establishes independent subscription sessions for each, or configures different filtering rules for the same session when the subscription point description supports filtering conditions, thereby ensuring that the pushed data is consistent with the component binding parameters.

[0110] In some examples, the data standardization module performs cleaning and transformation on the received incremental raw data. Unlike the standardization for batch queries, incremental raw data is typically a single point change or a single event record, and may contain incomplete fields or short-cycle jitter.

[0111] In this embodiment, the data standardization module still uses the dataset identifier as an index to read data standardization rules from the metadata repository, including field mapping relationships, data type conversion rules, and output structure constraints, and performs the following processing on the incremental raw data: First, based on the field mapping relationship, the location identifier, event attribute, or alarm field is mapped to a unified output field name; second, the location value is converted to a numerical type according to the data type conversion rules, the time field is formatted and the enumeration field is normalized; and third, the incremental data is encapsulated into a unified format data result according to the output structure constraints.

[0112] In some examples, to ensure the continuity of component-side rendering under incremental push, the data standardization module distinguishes between "incremental frame structure" and "full snapshot structure" in the output structure constraints: the incremental frame structure only contains changed fields, timestamps, and object identifiers, while the full snapshot structure contains the complete set of fields for the object. The data service execution module can choose to push incremental frames or periodically push full snapshots based on the update triggering method in the bound record to adapt to the rendering models of different components.

[0113] In some examples, the data service execution module pushes incremental, uniformly formatted data results to the visualization component according to the update triggering method corresponding to the bound records. The data update triggering methods recorded in the bound records include at least timed refresh, event-driven, or real-time push.

[0114] In this embodiment, when the binding record indicates real-time push, the data service execution module establishes a WebSocket push channel with the component during the component initialization phase and pushes the data immediately after receiving the incremental unified format data result. When the binding record indicates event-driven, the data service execution module decides whether to push based on the event type and triggering rules, for example, only pushing when the point value change exceeds the threshold or the alarm level meets the conditions. When the binding record indicates periodic refresh but the dataset type is a real-time subscription dataset, the data service execution module can adopt the "subscription reception + periodic summary push" method, that is, receive incremental raw data in real time and perform short-cycle caching or window aggregation on the server side, and push the summarized unified format data result in the window to the component when the periodic period arrives, thereby reducing the rendering frequency on the component side.

[0115] This embodiment controls the data agent to establish a long connection or WebSocket push channel to receive data change events when the dataset type is identified as a real-time subscription dataset. The data standardization module cleans and transforms the incremental raw data according to unified standardization rules, and then pushes it to the visualization component according to the update trigger method of the bound record. This enables industrial real-time data and alarm events to be continuously updated in a service-oriented push manner, reducing component-side polling requests and reducing access pressure on the industrial database, while improving the timeliness of large screen data updates and the reusability of multiple components.

[0116] In some embodiments, the data standardization module is specifically used for: Read the data standardization rules associated with the dataset identifier from the metadata repository. The data standardization rules include field mapping relationships, data type conversion rules, and output structure constraints. Perform cleaning processing on the raw data returned by the data broker. The cleaning processing includes one or more of the following: missing value handling, outlier handling, or character encoding conversion, to generate data to be converted that meets the data type conversion rules. Based on the field mapping relationship, field alignment and field renaming are performed on the data to be transformed, and the field values ​​are converted according to the data type conversion rules to generate structured data that matches the output structure constraints; Structured data is encapsulated into a unified format, and the unified format data is returned to the visualization component for visualization rendering through a unified data service interface.

[0117] Specifically, the data standardization module first reads the data standardization rules associated with the dataset identifier from the metadata repository. These rules include field mapping relationships, data type conversion rules, and output structure constraints. Field mapping relationships define the correspondence between raw data fields and standardized output fields; data type conversion rules define the target type of each output field and the conversion method from the raw representation to the target type; and output structure constraints define the structural form of the standardized data results, such as whether it is a record set structure, whether it contains time series points, whether it contains pagination fields, or whether it contains event attribute fields. After reading these rules using the dataset identifier as an index, the data standardization module loads them into the standardization context of this request, ensuring that subsequent cleaning and transformation processes can be executed under the same set of rule constraints.

[0118] In some examples, to ensure that rule version updates do not affect operational stability, the data standardization module reads the rule version identifier and update time when reading the data standardization rules, and stores them in association with the current request. When the rule version is found to be inconsistent with the cached result version, the data service execution module can choose to bypass the cache and re-standardize and generate the result to ensure that the returned data result meets the latest field definitions and structural constraints.

[0119] In this embodiment, the data standardization module then performs cleaning processing on the raw data returned by the data broker. This cleaning process includes one or more of the following: missing value handling, outlier handling, or character encoding conversion, to generate data to be converted that meets data type conversion rules. The raw data may come from different types of data brokers; its form may be multi-row, multi-column records from a database query result, nested objects in an interface response body, two-dimensional table data obtained from file parsing, or incremental point data received through real-time subscription. To accommodate these differences, this embodiment abstracts the cleaning process into a unified processing of "field value availability" and "field value resolvability."

[0120] In some examples, missing value handling includes processing null values, default fields, and invalid placeholders. For cases where a field in a database query result is empty, the data standardization module can fill the corresponding field with a default value according to data type conversion rules, or mark the field as missing and output it empty if allowed by output structure constraints. For cases where a field is missing in the interface response body, the data standardization module can determine whether the field is required based on the field mapping relationship and output structure constraints; if it is a required field, it generates a missing flag or triggers an exception return. For cases where empty cells exist in parsed file data, the data standardization module can uniformly convert empty cells to null value flags and fill them with default values ​​or discard the record during subsequent type conversions according to rules.

[0121] Outlier handling includes processing out-of-range values, illegal characters, and non-numeric text. For example, when a power field should be a value but the original data contains "-" or "NaN" text, the data standardization module can mark the field as missing and record the reason for the anomaly. When a temperature field exceeds the configured reasonable range, it can be truncated, set to empty, or retained according to rules, along with a quality label. Character encoding conversion is used to handle inconsistent string encodings returned from different data sources. For example, a file data source using a specific encoding may cause garbled Chinese characters in the field, or the interface may return strings containing escape characters. During the cleaning phase, the data standardization module converts strings to the target encoding and replaces or removes unresolvable characters to ensure the feasibility of subsequent field mapping and type conversion.

[0122] The following example illustrates the cleaning process. In one example, an Excel file records equipment inspection data. Some rows have an empty "Inspector" field, and the "Inspection Time" field has different formats. The data standardization module fills the "Inspector" field with "Unknown" according to rules in the missing value handling process and unifies the file encoding in the character encoding conversion process. In the outlier handling process, unparseable text in the "Inspection Time" field is set to empty and an anomaly marker is recorded for that row, so as to generate data to be converted that can enter the type conversion stage.

[0123] In some examples, the generation process of structured data also includes assembling the structure according to output structure constraints. Output structure constraints can limit the result to a single record, a set of records, a set of time-series points, or a set of events. For a set of records, the data standardization module converts each row of records into a structured record with aligned fields and adds pagination or total count information according to constraints. For a set of time-series points, the data standardization module organizes the point values ​​and time fields into time-series points according to constraints, and can sort by time or aggregate by window. For a set of events, the data standardization module organizes the alarm event fields into event records according to constraints, and retains the event time, level, and object identifier fields for scrolling display or alarm linkage on the component side.

[0124] In this embodiment, the data standardization module encapsulates structured data into a unified format data result and returns the unified format data result to the visualization component for visualization rendering through a unified data service interface. In some embodiments, the unified format data result is output using a standard JSON structure, which includes at least a dataset identifier, data timestamp or generation time, structured data body, and optional quality markers or error information fields.

[0125] The data standardization module includes a dataset identifier in the result header during encapsulation, enabling components to identify data sources in multi-dataset scenarios. It also includes the generation time in the result header for easy display of data refresh time on the component side. Structured data is written into the result body to meet the common parsing requirements of different components such as charts, tables, and animations. For real-time subscription of incremental data, the standardized data result can also include an incremental marker field to indicate whether the current result is an incremental frame or a full snapshot, allowing components to choose between incremental updates or full redraws.

[0126] This embodiment uses a data standardization module to load field mapping relationships, data type conversion rules, and output structure constraints using dataset identifiers as indexes. The raw data returned by the data agent is first cleaned, then aligned, renamed, and type converted. Finally, it is packaged into a unified format data result and returned or pushed to the visualization component. This enables multi-source heterogeneous data to achieve consistent field definitions and consistent structural forms on the output side, reducing component-side adaptation and repetitive parsing logic, improving the reusability and data consistency of large screen components, and reducing maintenance costs caused by field changes or data source differences.

[0127] Through the technical solutions provided in the above embodiments of this application, this application can achieve the following technical and economic effects: I. Technical Effects: 1) Significantly improved access efficiency: The complete access cycle for 7 types of data sources has been shortened from 2-3 weeks to ≤24 hours, and the access time for a single type of data source has been shortened from 2-4 days to ≤30 minutes, with an efficiency improvement of over 90%.

[0128] 2) Solving data consistency: Through a unified data model, the accuracy of data from 7 types of data sources has been improved from 80% to 99.5%. The same indicator is unbiased in different components of the dashboard, meeting the needs of monitoring and decision-making.

[0129] 3) Significantly enhanced scalability: Adding new data sources (such as additional CSV files or industrial alarm types) only requires inputting basic information, without the need for code development, achieving "add and use immediately"; when data source parameters change, the system automatically updates the configuration without manual intervention.

[0130] 4) Real-time performance of the large screen meets the standards: the real-time data push latency of the industrial database is ≤100ms, the alarm data is triggered and pushed (latency ≤50ms), and the Excel / CSV data supports 10-minute level updates, which fully meets the real-time monitoring needs of the Web large screen.

[0131] II. Economic Effects: 1) Reduce development costs: Eliminate the development costs of custom interfaces for 7 types of data sources, reducing the development cost of a single project by more than 60%; reduce the modification costs caused by changes in data sources during the operation and maintenance phase by 80%.

[0132] 2) Savings in labor costs: No professional developers are required (only maintenance personnel need to input data source information), reducing labor demand by 70%, and small and medium-sized manufacturing enterprises can complete the large screen data configuration independently.

[0133] 3) Improved production efficiency: Through real-time monitoring and rapid alarm response, unplanned equipment downtime is reduced by 25%, and production efficiency is increased by an average of 15%.

[0134] The above embodiments have described in detail the specific modules and functions of the unified data source interaction system for industrial HMI configuration of this application. The implementation process of the unified data source interaction method for industrial HMI configuration of this application will be described in detail below with reference to specific embodiments. Figure 2 This is a flowchart illustrating the intelligent chart configuration method for human-computer interface based on multimodal interaction provided in this application embodiment, as shown below. Figure 2 As shown, the intelligent chart configuration method for human-computer interface based on multimodal interaction may specifically include the following steps: S201, in the unified data source service layer, connection parameter configuration is performed for multiple heterogeneous data sources, and a dataset definition is generated based on the configured data source. The dataset definition includes a dataset identifier, parameter constraints, and an access description for obtaining data from the corresponding data source. S202, persistently store the connection parameter configuration and dataset definition to the metadata repository, and establish the mapping relationship between the dataset identifier and the corresponding data source, as well as the data standardization rules corresponding to the dataset; S203 establishes a binding relationship between visualization components and dataset identifiers in industrial HMI configuration, and records the data request parameters and data update triggering methods associated with the binding relationship; S204, during the operation phase, receives data requests from visualization components, including dataset identifiers and data request parameters, through a unified data service interface; reads the dataset definition corresponding to the dataset identifier from the metadata repository; and schedules a data agent matching the data source type to obtain the original data from the corresponding data source based on the mapping relationship. S205 performs cleaning and transformation on the raw data according to data standardization rules, generates data results in a unified format, and returns the unified format data results to the visualization component for visualization rendering.

[0135] 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 unified data source interaction system for industrial HMI configuration, characterized in that, include: The multi-source adaptation module is used to configure connection parameters for multiple heterogeneous data sources in the unified data source service layer, and generate dataset definitions based on the configured data sources. The dataset definitions include dataset identifiers, parameter constraints, and access descriptions for obtaining data from the corresponding data sources. The metadata persistence module is used to persistently store the connection parameter configuration and the dataset definition in the metadata repository, and to establish the mapping relationship between the dataset identifier and the corresponding data source and the data standardization rules corresponding to the dataset. The component binding module is used to establish a binding relationship between visualization components and the dataset identifier in the industrial HMI configuration, and to record the data request parameters and data update triggering methods associated with the binding relationship; The data service execution module is used to receive data requests containing dataset identifiers and data request parameters initiated by the visualization component through the unified data service interface during the runtime phase, read the dataset definition corresponding to the dataset identifier from the metadata repository, and schedule a data agent matching the data source type to obtain raw data from the corresponding data source based on the mapping relationship. The data standardization module is used to clean and transform the raw data according to the data standardization rules, generate data results in a unified format, and return the data results in a unified format to the visualization component for visualization rendering.

2. The system according to claim 1, characterized in that, The multi-source adaptation module is specifically used for: Receive data source configuration requests for different data source types, and generate corresponding data source connection descriptions based on the data source configuration requests; A dataset definition is created based on the data source connection description, and a dataset identifier is assigned to the dataset definition. The dataset definition includes parameter constraints associated with the dataset identifier, an access description for obtaining data from the corresponding data source, and an output field description corresponding to the access description. Define a data update strategy for the dataset, which includes a cache duration and / or update trigger conditions, for subsequent data request processing based on the dataset identifier.

3. The system according to claim 2, characterized in that, The dataset definition includes one or more dataset type identifiers, which are used to indicate the query or subscription method corresponding to the dataset definition. The dataset type identifier includes one or more of the following: database query dataset, interface request dataset, file parsing dataset, and real-time subscription dataset. The access description includes a query statement description, request template description, parsing rule description, or subscription point description that matches the dataset type identifier.

4. The system according to claim 1, characterized in that, The process of establishing the mapping relationship between the dataset identifier and the corresponding data source, as well as the data standardization rules corresponding to the dataset, includes: The dataset identifier is associated with and stored in the dataset definition with the data source type, data source connection description and access description, so as to generate a mapping relationship for locating the target data source and selecting a data agent that matches the data source type during the runtime phase; Based on the output field descriptions in the dataset definition, establish field mapping relationships, and combine the data source type to configure data type conversion rules and output structure constraints to generate data standardization rules associated with the dataset identifier; The mapping relationship and the data standardization rules are written into the metadata repository and stored in association with the dataset identifier, so that the data service execution module can call it when it receives a data request containing the dataset identifier.

5. The system according to claim 1, characterized in that, The component binding module is specifically used for: In the configuration interface, select or input the dataset identifier for the target visualization component, and generate a binding record corresponding to the visualization component and the dataset identifier; Configure data request parameters corresponding to the dataset identifier in the binding record. The data request parameters include one or more of query parameters, filter conditions, or path parameters, and are used by the data service execution module to generate a data request containing the dataset identifier and the data request parameters during the runtime phase. Configure a data update triggering method in the binding record. The data update triggering method includes at least one or more of timed refresh, event-driven, or real-time push. The event-driven method includes triggering updates based on changes in the data request parameters or changes in the data source. The binding record is written to the metadata repository or configuration configuration file and stored in association with the visualization component identifier, so that during the runtime phase, the visualization component can be driven to request and receive data results in a unified format based on the binding record.

6. The system according to claim 1, characterized in that, The data service execution module is specifically used for: The unified data service interface receives data requests initiated by the visualization component, which include the dataset identifier and data request parameters. It performs permission verification on the data request based on the access control policy associated with the dataset identifier in the metadata repository, and performs validity verification on the data request parameters based on the parameter constraints in the dataset definition. The dataset definition corresponding to the dataset identifier and the mapping relationship associated with the dataset identifier are read from the metadata repository. The data source type and the data source connection description are determined according to the mapping relationship. A data agent matching the data source type is selected according to the data source type. The data update strategy associated with the dataset identifier is read. The access description and the data request parameters are passed to the data broker, which then establishes a connection with the corresponding data source based on the data source connection description and performs a data acquisition operation that matches the access description to obtain the original data.

7. The system according to claim 2 or 6, characterized in that, The data service execution module is also used to generate a cache key for the dataset identifier and the data request parameters when the data update strategy indicates that caching is supported, and to perform a cache hit determination on the data results in a unified format based on the cache key and a preset cache duration. If a valid cache is hit, the data results in the unified format are returned directly. If a valid cache is not hit, the data proxy is triggered to obtain the original data.

8. The system according to claim 6, characterized in that, When the dataset type identifier indicates a real-time subscription dataset, the data service execution module controls the data agent to establish a long connection or WebSocket push channel to receive data change events. The data standardization module performs the cleaning and transformation on the received incremental raw data and pushes the incremental data results in a unified format to the visualization component according to the update triggering method corresponding to the bound record.

9. The system according to claim 1, characterized in that, The data standardization module is specifically used for: Read the data standardization rules associated with the dataset identifier from the metadata repository. The data standardization rules include field mapping relationships, data type conversion rules, and output structure constraints. The original data returned by the data agent is cleaned, and the cleaning process includes one or more of missing value processing, outlier processing, or character encoding conversion, to generate data to be converted that meets the data type conversion rules; Based on the field mapping relationship, field alignment and field renaming are performed on the data to be converted, and type conversion is performed on the field values ​​according to the data type conversion rules to generate structured data that matches the output structure constraints; The structured data is encapsulated into a unified format data result, and the unified format data result is returned to the visualization component for visualization rendering through the unified data service interface.

10. A unified data source interaction method for industrial HMI configuration based on the system described in any one of claims 1 to 9, characterized in that, include: In the unified data source service layer, connection parameters are configured for multiple heterogeneous data sources, and a dataset definition is generated based on the configured data source. The dataset definition includes a dataset identifier, parameter constraints, and an access description for obtaining data from the corresponding data source. The connection parameter configuration and the dataset definition are persistently stored in the metadata repository, and a mapping relationship between the dataset identifier and the corresponding data source and the data standardization rules corresponding to the dataset are established. In the industrial HMI configuration, a binding relationship is established between the visualization component and the dataset identifier, and the data request parameters and data update triggering methods associated with the binding relationship are recorded; During the operation phase, the system receives data requests containing dataset identifiers and data request parameters initiated by the visualization component through the unified data service interface, reads the dataset definition corresponding to the dataset identifier from the metadata repository, and schedules a data agent matching the data source type to obtain raw data from the corresponding data source based on the mapping relationship. The raw data is cleaned and transformed according to the data standardization rules to generate data results in a unified format, and the unified format data results are returned to the visualization component for visualization rendering.

Images