Unified data management method and system for industrial automation

Abstract

In a unified data management system for industrial automation, a query request is received via a unified query API layer configured to expose a universal interface for accessing data from a persistent storage layer that includes a plurality of data stores that ingest data from a plurality of data sources, respectively, in the automation system. The data store includes different access APIs and data patterns. Query parameters are extracted from the unified query API layer to construct, by a query builder, a dedicated query for a particular data storage construction using the semantic layer. The semantic layer may map queries to respective data stores based on contextual information derived from query parameters, and provide access to the respective data stores based on respective access APIs and data schema for the respective data stores. Dedicated queries are executed directly on a particular data store by a query engine, and query results are returned via a unified query API layer.

Description

Technical Field

[0001] The present disclosure relates generally to industrial automation systems, and more particularly to methods, systems, and computer program products for unified data management of data generated in automation systems. Background Art

[0002] In today's industrial automation, such as in manufacturing, more and more data is generated in the field. For example, a typical factory can generate about 1TB of data per day. This trend is expected to continue with the emergence of more and more so-called "Internet of Things" or IoT devices, such as industrial cameras, wearable devices, VR / AR devices, etc., which can all participate in the automation process. In many industries, regulations, safety and quality control may require continuous storage of all important data. The data may need to be accessed by applications to perform data analysis or other tasks.

[0003] As more and more data of various types are ingested into automated processes, accessing and using non-uniform data in different data stores (or databases) may become increasingly cumbersome and time-consuming. Each data store may have its own schema, access API, communication / message protocol, etc. Accessing data from different data stores may require detailed knowledge of the various properties of different data stores, which may increase application development cycles and lead to large and monolithic applications that are difficult to develop and maintain, especially as more and more data of various types are ingested into automated processes. Summary of the invention

[0004] In short, various aspects of the present disclosure provide a unified data management system and method for industrial automation, which can solve the above-mentioned technical problem, namely, in an automation system, the problem of achieving non-uniform data access for a large and increasing number of data sources with different data types and different raw data formats and modes.

[0005] According to a first aspect, a data processing system for an automation system is provided. The data processing system includes one or more processors and a non-transitory memory, the non-transitory memory storing a software stack, the software stack including a computing module executable by the one or more processors. The software stack includes a unified data management module. The unified data management module is configured to receive a query request via a unified query API layer. The unified query API layer is configured to expose a common interface for accessing data in a persistent storage layer, the persistent storage layer including multiple data stores, which ingest data from multiple data sources in the automation system, respectively, wherein the multiple data stores include different access APIs and data modes. The unified data management module is configured to extract query parameters from the unified query API layer, and use the extracted query parameters to build a dedicated query for a specific data store through a query builder using a semantic layer. The semantic layer is configured to map the query to each data store based on context information derived from the query parameters, and provide access to each data store based on the corresponding access API and data mode of each data store. The unified data management module is configured to execute a dedicated query directly on a specific data store through a query engine, and return the query result via the unified query API layer.

[0006] Further aspects of the present disclosure relate to a corresponding computer-implemented method and a computer program product comprising instructions executable by a data processing system to perform the above method.

[0007] Another aspect of the present disclosure relates to an automation system. The automation system includes a controller for controlling a physical device. The controller includes a computing device having an open real-time platform, which includes: an inter-application communication layer, providing one or more APIs that can be used by multiple processes running on the controller to achieve standardized communication between processes; and a real-time execution service, providing one or more APIs that can be used by multiple processes to coordinate the execution of control loops based on real-time requirements. The automation system also includes an engineering system. The engineering system includes one or more processors, and a non-volatile memory that stores instructions that can be executed by one or more processors to generate a control app through the above method for deployment on the controller. The deployed control app is therefore configured to execute a control loop on the controller using the API provided by the inter-application communication layer and the real-time execution service.

[0008] Additional technical features and benefits can be achieved through the technology of the present disclosure. The embodiments and aspects of the present disclosure are described in detail herein, and these embodiments and aspects are considered to be part of the claimed subject matter. For a better understanding, reference is made to the detailed description and the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The foregoing and other aspects of the disclosure are best understood from the following detailed description when read in conjunction with the accompanying drawings. To easily identify discussion of any element or action, the most significant digit in a reference numeral refers to the digit number that first introduces that element or action.

[0010] Figure 1 is a high-level block diagram of a system for unified data management in an automation system in accordance with aspects of the present disclosure.

[0011] Figure 2 is a block diagram illustrating components of a unified data management module (UDM).

[0012] Figure 3 An example of a process historian for an automation system including a UDM in accordance with disclosed embodiments is shown.

[0013] Figure 4 An example of query execution using a UDM module according to the disclosed embodiments is shown.

[0014] Figure 5 is a schematic diagram showing the integration of the UDM module into multiple locally deployed and cloud-based data processing systems. DETAILED DESCRIPTION

[0015] Embodiments of the disclosed method relate to a data management solution for an automation system that can provide unified access to data from a large number of different data sources (including various field devices, controllers, etc.) that produce data of different data types with different data characteristics. The disclosed method is particularly suitable for application to a process historian in an automation system. A process historian (or data historian) is a software and hardware solution for data management in the field of industrial automation that can archive historical process data (e.g., digital and analog inputs and outputs) from automation field devices and controllers and provide an interface for applications (apps) to access and retrieve the data.

[0016] To achieve data persistence in the automation process, data from different data sources is ingested into dedicated data stores on permanent storage media. For example, process values ​​like temperature can be stored in a time series database, plant asset information can be stored in a relational database, images from inspection cameras can be stored in a file server, etc. Each data store can have its own data schema, access API (short for application programming interface), communication / messaging protocol, etc.

[0017] In many automation systems, the logic for accessing data from different data stores is often implemented inside the app. As a result, the app manages the data schema, access API, communication / messaging protocols, etc. for each data store. However, any changes, such as adding a new data source or changing the database schema, may require corresponding changes to the app. This can lead to large and monolithic apps that are difficult to develop and maintain, especially as more and more types of data are ingested into the automation process.

[0018] In some automation systems, apps do not access data directly from data stores, but rather through a plant data model. A plant data model can be built using standards such as Open Platform Communications Unified Architecture (OPC UA), which sits between the data and the app. A plant data model based on OPC UA can provide a semantically rich, graph-based data structure that apps can query to access automation data (including real-time data, historical data, and contextual data). An example of such a plant model is described in European Patent Application No. 22182015.2, which is incorporated herein by reference in its entirety. In this case, the app is based on a standard supported by the plant data model (e.g., OPC UA). The plant data model typically contains data service components (e.g., specific connectors for each data source) that are needed to import data from the data store into the model, where the data imported into the model can be accessed by the app.

[0019] Embodiments of the disclosed methods may provide improvements over any of the known methods described above.

[0020] Figure 1A high-level view of a system 100 for data management in an automation system according to a disclosed embodiment is shown. The automation system includes multiple data sources 102, which may include controllers (e.g., programmable logic controllers or PLCs), field devices (e.g., sensors, actuators), servers, and other IoT devices. Data from each data source 102 is ingested into a corresponding data store 104 on a persistent storage medium, and at least in some cases, the data store is local to the data source 102. As described above, the data store 104 exposes different access APIs and data schemas. The disclosed method is based on abstracting data management functionality (such as management of different data store access APIs, data schemas, etc.) into a module, referred to in the present invention as a unified data management module (or UDM module or simply UDM) 106. The UDM 106 provides a unified query interface for modular applications or apps 108 to access data directly from the data store 104. The provision of the UDM 106 enables the development of apps 108 that are open and agnostic to the data attributes of the data store 104, which are essentially "hidden" from these apps.

[0021] The UDM 106 can eliminate the requirement for a plant data model. Figure 1 As shown, the UDM 106 can also be integrated with existing automation products that provide data access to apps 112 via the plant data model 110 described above. In this case, as shown, the UDM 106 can be provided as a layer below the plant data model 110. Since data management functions (such as management of different data storage access APIs, data schemas, etc.) are abstracted into the UDM 106, the plant data model 110 can be simplified without the need for the above-mentioned data service components. Existing apps 112 that were developed to access data via the plant data model 110 (e.g., based on the OPC UA standard) can still be used without modification.

[0022] According to the disclosed embodiments, Figure 2 As shown, UDM 106 is implemented via the following layers, namely, persistent storage layer 202, semantic layer 204, and unified query API layer 206. Exemplary implementations of these layers are described below.

[0023] The persistent storage layer 202 forms the lowest layer of the UDM 106, which includes multiple data stores. The data stores may be specialized for the characteristics of the data generated by various data sources. For example, images from a camera may be stored in a file system, audio or vibrations from an acoustic sensor may be stored in an audio file system or a time series database, alarms may be stored in a table or relational database, media content may be stored in a BLOB database, and so on. Thus, the persistent storage layer 202 utilizes data stores that ingest raw data from the data sources. This ensures that the original data is preserved without any copying or importing / exporting of data (e.g., compared to cloud-based data lake implementations). Thus, at least some of the data stores in the persistent storage layer 202 may be on a persistent storage medium local to the data source.

[0024] If the data source does not have local persistent storage, the UDM 106 may provide one or more pre-built data stores as part of the persistent storage layer 202 for ingesting raw data directly from the data source. Such pre-built data stores may be optimized for data attributes associated with the data source. In this case, the UDM 106 may provide an additional ingestion API layer (not shown) between the persistent storage layer 202 and the data source. The ingestion API layer may include a set of one or more connector APIs, such as OPC UA, OLE DB, structured text, XML DA, MQTT unstructured data, Modbus, etc. In an embodiment, the ingestion API layer is configurable based on the implementation scale of the UDM 106.

[0025] The semantic layer 204 provides a mechanism for the unified query API layer 206 to query the data in the persistent storage layer 202. The semantic layer 204 manages the context of data from different data sources and data stores. The semantic layer 204 is used to map queries from query requests to specific data stores based on context information, and the query requests are received via the unified query API layer 206. The context information may include, for example, data types and / or data store identifiers extracted from query parameters of the query request. The semantic layer 204 is also used to access various data stores in the persistent storage layer 202 based on the corresponding access APIs and data modes of the various data stores.

[0026] In one embodiment, the semantic layer 204 may include a service registry for each data store that contains addresses, data types, evaluation APIs, and data schemas. The data store addresses may be defined based on the type of connection available between the semantic layer 204 and each data store (e.g., an IP address in the case of a TCP / IP connection). In some cases, the service registry may contain a specific data store ID or key for each data store, where multiple data stores are mapped to a single address (e.g., the same physical storage hardware). In some embodiments, the semantic layer 204 may, for example, dynamically detect the state of the data store (online / offline) via publisher-subscriber based communications. Thus, the semantic layer 204 may intelligently detect newly added data stores. Based on the information published by the data store, the pedigree of the newly added data store with the data source may also be automatically established.

[0027] The semantic layer 204 may be coupled to or be a part of the overall professional data management layer of the UDM 106, which includes a set of other components, such as data cleansing, data transformation, data compression, data indexing, database management system (e.g., relational DB, graph DB, time series DB), etc. In an embodiment, the entire professional data management layer may be configured based on the implementation scale of the UDM 106.

[0028] The unified query API layer 206 exposes a common interface for accessing data from different data stores in the persistent storage layer 202. The unified query API layer 206 receives a query request (e.g., from an application, a factory data model, or a user), which includes query parameters constructed in a simple unified syntax. The query builder extracts the query parameters from the unified query API layer 206, and uses the semantic layer 204 to construct a dedicated query for a specific data store based on the extracted query parameters including context information for mapping the query to a specific data store. Since data stores may have different addresses, support different modes, and expose different access APIs, the dedicated query constructed using the semantic layer 204 is specifically constructed for each data store and may be different from the query request constructed in the unified syntax. Therefore, the semantic layer 204 can be used to transform or convert a query request in a simple unified format into a dedicated query constructed in a professional format, which can be routed to a specific data store, which may be local to the data source. Then, the dedicated query is executed directly on the specific data store by the query engine, and the query result is returned via the unified query API layer in a simple, unified format understandable to the application, factory data model, or user.

[0029] For certain types of query requests, based on context information derived from query parameters, the query builder can construct multiple specialized queries from the query request using the semantic layer 204, each of which is constructed separately for a specific data store. The multiple specialized queries can be executed directly on the specific data store by the query engine, and the aggregated data is returned in the form of summary query results via the unified query API layer 206.

[0030] like Figure 2 As shown, the unified query API layer 206 may include a set of programming APIs 208 to provide programmatic access to data in the persistent storage layer 202 through the application of the automation system or the plant data model. Non-limiting examples of applications that can use the UDM 106 to access data directly or via the plant data model may include performance monitoring / diagnostics, data analysis, digital twins, and other apps. The programming API may include an interface based on one or more of the following: REST API, Graph QL, SQL, OData, etc. Alternatively or additionally, the unified query API layer 206 may include one or more physical data access APIs 210 to provide users with physical data access from the persistent storage layer 202 to retrieve data therefrom. Therefore, the UDM 106 can provide users with a unified interface to retrieve raw data stored locally at a data source (e.g., by copying the data to a flash drive) without having to physically visit the plant. For example, the physical data access API 210 can be appropriately implemented using a command line interface (CLI). In an embodiment, the unified query API layer 206 can be configured based on the implementation scale of the UDM 106.

[0031] Figure 3 An example of process historian software 300 is shown, which includes a UDM 106 according to one or more disclosed embodiments to provide an interface to access historical process data. The process data is generated by data sources 102 on the plant floor, which may include multiple field devices, controllers, and other IoT devices. For example, the process data may include digital and / or analog input and output data of such devices. The process data can be ingested into data stores 302 local to certain data sources 102. The UDM 106 retains these data stores 302 in the persistent storage layer 202 without any replication of the process data. The UDM 106 can provide pre-built data stores 304 as part of the persistent storage layer 202 in the process historian 300 of the data source 102 without the need for local storage.

[0032] According to the disclosed embodiments, the process historian software 300 including the UDM 106 is modular and configurable according to the implementation scale of different automation levels, for example, at the machine level (such as on a PLC or other controller), at the edge computing level (such as on an industrial PC), at the enterprise level (such as on a SCADA system), or at the cloud level. For example, to build a specialized, low-footprint embedded historian on a constrained device (low computing power and memory) that only acquires data from one type of sensor and forwards the data to an external server, the following base libraries can be selected: a single connector API module (e.g., Modbus) in the ingestion API layer, a single data store (e.g., file-based storage), a simple database management system (e.g., time series DB) in the specialized data management layer, and REST API support (e.g., Web) in the unified query API layer. In another use case, a full-featured enterprise-level process historian can be configured by including more base libraries in the layers that provide more functionality (e.g., time series DB, graph DB, distributed object storage, ...), more interfaces in the ingestion API layer (e.g., OPC UA, Modbus, MQTT, etc.) and the unified query API layer to obtain data to provide access to various types of applications (e.g., Web app, C++ native app, SQL client, etc.).

[0033] In an embodiment, a historian / UDM configurator may be provided to configure the base libraries to be included in each UDM layer. The input to the configurator may include, for example, a configuration specification in an appropriately formatted format, such as an XML configuration file, which may list the libraries to be included in each UDM layer. In some embodiments, a low-code platform may be provided to program the interactions between base libraries within the UDM layer, on which a user is able to program workflows by establishing links between base libraries. Thus, the historian / UDM may be configured on a low-code platform to run on different automation levels, such as as a library module in an application on an embedded device (e.g., a controller or HMI device), as a containerized app on an edge computing device or in a virtual device hosted by a data center server, as a cloud-based software as a service (SaaS) or platform as a service (PaaS) hosted in a public cloud (e.g., Google™ Cloud, Azure™, etc.), and the like.

[0034] Figure 4An example of query execution using the UDM module according to the disclosed method is shown. In this example, the persistent storage layer 202 includes the following data stores, namely, a plant information data store 402a (relational database), a plant operation data store 402b (time series database), an image repository 402c (file system), a document repository 402d (such as a document database of MongoDB), and a part information data store 402e (relational database). The unified query API layer 206 includes a REST API interface 404, which can receive query requests constructed in a unified syntax applicable to all data stores. An example of a query request based on JavaScript Object Notation (JSON) is given below:

[0035] Example of a query request

[0036] {"plantID 0001",

[0037] "queryID": 1,

[0038] "query": [

[0039] {

[0040] "context": "PARTS",

[0041] "criteria": "PART_HISTORY < 10 YEAR"

[0042] },

[0043] {

[0044] "context": "TEMERATURE",

[0045] "criteria": "LAST 1 DAY"

[0046] } ]

[0048] }

[0049] The query request may be executed by the unified query API layer 206 as follows. First, the query builder 406 extracts query parameters from the REST API interface 404. According to the exemplary format, the query parameters include "context" and "criteria". In this example, the context is established only by data types such as "part" or "temperature". In some embodiments, there may be more than one data store with the same data type, in which case, the context may be established using, for example, a data store identifier in addition to or instead of the data type (e.g., "temperature 01").

[0050] The query builder 406 consults the semantic layer 204 based on the context information derived from the query parameters to build one or more specialized queries. For example, the query builder 406 can look up a service registry of data stores in the semantic layer 204 to map queries to various data stores based on the data type (context). In this case, the specialized queries are mapped to data stores 402e and 402b based on the contexts "parts" and "temperature", respectively. After the data stores are determined, specialized queries can be built based on the "standards" derived from the query parameters and using information in the data storage service registry (such as address, access API, and data schema).

[0051] After the specialized queries are constructed by the query builder 406, the query engine 408 executes these queries on the corresponding data stores 402e and 402b. The REST API interface summarizes the data aggregated from the data stores 402e and 402b and returns it as the query results. An example of the query results as a JSON message is presented as follows:

[0052] Example of query results

[0053] {

[0054] "plantID": "0001",

[0055] "queryID": 1,

[0056] "result":[

[0057] {

[0058] "TEMERATURE": [

[0059] {

[0060] time: 12334456,

[0061] value: 50

[0062] },

[0063] {

[0064] time: 12334460,

[0065] value: 55

[0066] },

[0067] {

[0068] time: 12334480,

[0069] value: 60

[0070] }, ... ]

[0073] }

[0074] {

[0075] "PARTS": [

[0076] {

[0077] "ID": “001",

[0078] "PART_ID": "0000000034343",

[0079] "PART_DESCRIPTION":

[0080] "REMAIN_LIFE": 20000

[0081] },

[0082] {

[0083] "ID": "002",

[0084] "PART_ID": "0000000034344",

[0085] "PART_DESCRIPTION":

[0086] "REMAIN_LIFE": 10000

[0087] }, ... ]

[0090] } ]

[0092] }

[0093] Aspects of the disclosed methods may be implemented by a data processing system. Such a data processing system may include one or more processors and non-volatile memory, the non-volatile memory storing a software stack, the software stack including computing modules executable by the one or more processors, wherein the software stack includes a UDM according to one or more disclosed embodiments. The processing power of the data processing system may be distributed among multiple system components, such as between multiple processors and memories, optionally including multiple distributed processing systems or cloud / network elements.

[0094] Figure 5 is a schematic diagram showing the integration of UDM into multiple local deployment and cloud-based data processing systems. The automation system may include different types of data processing systems at various automation levels (e.g., machine level, edge computing level, enterprise level, and cloud level), each running a respective version of UDM, which may be configured based on the specific requirements of each data processing system. As shown, a first local data processing system 502 (such as an edge computing device) may include one or more processors 504 and a local memory 506, the local memory 506 storing a software stack including a plant data model 522 located on top of the UDM 106 and one or more apps 524, wherein the app 524 may query the UDM 106 through the plant data model 522 based on a standard such as OPC UA. The UDM 106 provides a unified query API to the plant data model 522 to access data in the persistent storage layer. A second local data processing system 508, such as a human machine interface (HMI) device, may include one or more processors 510 and local memory 512 storing a software stack including one or more apps 526 located on top of the UDM 106, wherein the UDM 106 may allow direct access to the apps 528 to query data in the persistent storage layer. The UDM 106 may also allow a user to interact with the data processing system 508 to retrieve data from the persistent storage layer through physical data access 528. The third data processing system 514 may be implemented in a cloud computing environment, wherein data is synchronized with a cloud version of the UDM 106, providing cloud-based apps 530 with direct access to data, which may provide a nearly unlimited and highly scalable solution.

[0095] Embodiments of the present invention may be implemented using any combination of hardware and software. In addition, embodiments of the present disclosure may be included in an article (e.g., one or more computer program products) having, for example, a non-transitory computer-readable storage medium. The computer-readable storage medium contains, for example, computer-readable program instructions for providing and facilitating the mechanisms of embodiments of the present disclosure. The article may be included as part of a computer system or may be sold separately.

[0096] A computer-readable storage medium may include a tangible device capable of retaining and storing instructions used by an instruction execution device. A computer-readable storage medium may be, for example but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a corresponding computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or downloaded to an external computer or external storage device.

[0097] The systems and processes of the accompanying drawings are not exclusive. Other systems, processes, and menus can be derived according to the principles of the present disclosure to achieve the same goals. Although the present disclosure has been described with reference to specific embodiments, it should be understood that the embodiments and variations shown and described herein are for illustrative purposes only. Modifications to the current design can be implemented by professionals in the technical field without departing from the scope of the appended claims.

Claims

1. A data processing system for an automation system, comprising: one or more processors; as well as A non-transitory memory storing a software stack including a computing module executable by the one or more processors, the software stack including a unified data management module, the unified data management module being configured to: receiving a query request via a unified query API layer, the unified query API layer being configured to expose a common interface for accessing data in a persistent storage layer, the persistent storage layer comprising a plurality of data stores, the plurality of data stores respectively ingesting data from a plurality of data sources in the automation system, wherein the plurality of data stores comprise different access APIs and data modes; Extracting query parameters from the unified query API layer, and using the extracted query parameters to construct a specialized query for a specific data store using a semantic layer through a query builder, wherein the semantic layer is configured to map the query to each data store based on context information derived from the query parameters, and provide access to each data store based on a corresponding access API and data schema of each data store; and The dedicated query is directly executed on the specific data store by the query engine, and the query result is returned through the unified query API layer.

2. The data processing system according to claim 1, wherein: The unified query API layer includes one or more first APIs for providing programmatic access to data in the persistent storage layer through an application or factory data model located above a unified data management module in the software stack.

3. The data processing system according to claim 1 or 2, wherein: The unified query API layer includes one or more second APIs for providing physical data access from the persistent storage layer by a user interacting with the data processing system to retrieve data from the persistent storage layer.

4. The data processing system according to any one of claims 1 to 3, wherein: The persistent storage layer is implemented at least in part by a data storage local to the corresponding data source.

5. The data processing system according to claim 4, wherein: The unified data management module provides one or more pre-built data stores as part of the persistent storage layer to ingest data from one or more data sources without local storage, the one or more pre-built data stores being configured based on data types associated with the one or more data sources.

6. The data processing system according to any one of claims 1 to 5, wherein: The context information includes a data store identifier and / or a data type specified in the query parameter.

7. The data processing system according to any one of claims 1 to 6, wherein: The semantic layer includes a registry for each data store in the persistent storage layer, the registry containing an address, a data type, an evaluation API, and a data schema.

8. The data processing system according to any one of claims 1 to 7, in, Based on the context information, the query builder uses the semantic layer to construct a plurality of specialized queries from the query request, each specialized query being constructed for a specific data store, and The multiple dedicated queries are directly executed on the specific data storage by the query engine, and the aggregated data is returned in the form of summary query results via the unified query API layer.

9. The data processing system according to any one of claims 1 to 8, wherein: The semantic layer is also configured to dynamically detect the status of existing data stores and new data stores added to the persistent storage layer.

10. The data processing system according to any one of claims 1 to 9, comprising process history recording software, the process history recording software comprising the unified data management module for providing an interface for accessing historical process data of the automation system, in, The data sources include field devices and / or controllers of the automation system, and The process data generated by the data source includes digital and / or analog input and output data.

11. The data processing system according to any one of claims 1 to 10, wherein: The unified data management module is modular and configured by using a configurator to select basic libraries at different levels of the unified data management system based on the automation level at which the data processing system operates, wherein the automation level is selected from the group consisting of: machine level, edge computing level, enterprise level and cloud level.

12. The data processing system according to claim 11, wherein: The configurator provides a low-code platform for users to program workflows by defining interactions between selected base libraries in a unified data management module layer.

13. A method for providing unified access to data generated in an automation system, comprising: receiving a query request via a unified query API layer, the unified query API layer being configured to expose a common interface for accessing data in a persistent storage layer, the persistent storage layer comprising a plurality of data stores, the plurality of data stores respectively ingesting data from a plurality of data sources in the automation system, wherein the plurality of data stores comprise different access APIs and data modes; Extracting query parameters from the unified query API layer, and using the extracted query parameters to construct a specialized query for a specific data store using a semantic layer through a query builder, wherein the semantic layer is configured to map the query to each data store based on context information derived from the query parameters, and provide access to each data store based on a corresponding access API and data schema of each data store; and The dedicated query is directly executed on the specific data store by the query engine, and the query result is returned via the unified query API layer.

14. A non-transitory computer-readable storage medium encoded with instructions that, when processed by a data processing system, configure the data processing system to perform the method of claim 13.

Images