System for accessing production data

Abstract

The invention relates to a system (120) for accessing production data of a production plant (130, 132, 134). The production data is stored on a plurality of databases (131, 133, 135). The abstraction layer (121) is adapted to access each of the databases for retrieving production data from the database and for providing the retrieved data for further processing. A model interface (122) is adapted to run analysis workloads that require production data from the databases and is further adapted to cause the abstraction layer to retrieve desired predetermined production data from the databases and provide the retrieved desired predetermined production data to the analysis workloads running on the model interface. This allows any type of production data stored on multiple databases to be accessed anywhere and at any scale while requiring less computing resources.

Description

Technical Field

[0001] The present invention relates to a system, method and computer program product for accessing production data of one or more production plants. Further, the present invention relates to a user model interaction environment and the use of the system, method and computer program product for accessing production data. Background Art

[0002] In modern industrial production processes, a large amount of production data, i.e., process data, is generated, for example, including sensor measurement results, control data, quality data, etc. Typically, process data is stored locally, for example, on a corresponding database set at a specific production site. These massive data include a lot of information, which becomes particularly interesting when using the most advanced big data analysis tools currently available. In particular, analyzing these data can bring about a variety of improvements in the context of the production process, for example, saving resources, streamlining the production process, or developing new favorable production processes. However, accessing these theoretically available massive data is usually difficult. In many cases, for such analysis tools, not only data from one production site is required, but also production data from multiple production sites need to be accessed and processed, which requires access to all corresponding local storage devices containing data. This actually leads to a variety of difficulties, which often hinder the beneficial use of locally stored process data. It would be advantageous to provide a solution that allows access to any type of production data from anywhere and at any scale while requiring less computing resources. Summary of the invention

[0003] The object of the present invention is to provide a system, a computer-implemented method and a computer program product to allow access to any type of production data stored on multiple databases from anywhere and at any scale while requiring fewer computing resources.

[0004] In a first aspect of the present invention, a system for accessing production data of one or more production plants is proposed, wherein the production data is stored in multiple databases, wherein the system includes: a) an abstraction layer, which is suitable for accessing each of the multiple databases for retrieving production data from the corresponding database and for providing the retrieved data for further processing; and b) a model interface, which is suitable for running an analytical workload that requires predetermined production data from one or more databases of the multiple databases, and is further suitable for enabling the abstraction layer to retrieve the required predetermined production data from one or more databases of the multiple databases and provide the retrieved required predetermined production data to the analytical workload running on the model interface.

[0005] Since the system provides an abstraction layer suitable for accessing each of the multiple databases and a model interface suitable for running an analysis workload that requires production data from the database, only the abstraction layer directly accesses the database, and any analysis workload is provided as part of the model interface. Therefore, the analysis workload can access the corresponding required production data from anywhere (i.e., from different network locations) via the abstraction layer. In addition, the abstraction layer further allows access to the required production data, while the model interface (especially the analysis workload running on the model interface) does not have to be familiar with the type and / or scale of the required production data stored on any storage device. Therefore, the analysis workload can access any type of production data required from anywhere and at any scale via the abstraction layer. In addition, since the required production data is only provided to the analysis workload when needed, that is, since the production data is usually not copied to some other location in, for example, a cloud environment, the abstraction layer allows saving computing resources, especially storage resources. In addition, the abstraction layer further allows access to the required production data, while the model interface (especially the analysis workload running on the model interface) does not have to be familiar with the type and / or scale of the required production data stored on any storage device, and the data model (e.g., the data format used by the model interface or the analysis workload) can be unified. This reduces, among other things, the dependency on specific application programming interfaces.Furthermore, the abstraction layer allows for the retrieval of data using more efficient protocols, which improves performance and efficiency, allows for high data consistency, and avoids delays during data requests.

[0006] Generally, the production data of one or more production plants may refer to any type of data type or format, and further may refer to any type of content related to the production process of the production plant. In particular, the production data may refer to production time series data and / or production event data. The production time series data may refer to a sequence of any time-related data values ​​associated with a corresponding tag (e.g., with a corresponding sensor or control process). Preferably, the production time series data includes time-related data values, which refer to the measurement results of sensors provided in the production plant for monitoring the production process of the production plant. In addition, the production time series data may also refer to control data for monitoring and controlling the production process in the production plant. Production event data may refer to any data associated with a specific event. In particular, although the production event data may be generated at a specific time interval and may be time-related within this time interval, the production event data may not necessarily include time-related data values. For example, the production event data may refer to error data generated during a failure of a part of the production process, service data generated during a maintenance action performed on one or more parts of the production plant, transition data generated during the transition of the production plant from one production to another, etc. These correspondingly generated production data are all stored on multiple databases associated with one or more production plants. For example, the production data may be stored in one or more of the plurality of databases continuously, at predetermined time intervals, or at least once in a while. Typically, the location of the plurality of databases may be anywhere, as long as the respective databases are communicatively connected to the respective production data generation layers of the respective production plants. For example, the databases may refer to local databases provided as part of a local computing system of the production plant (e.g., as part of a control system of the production plant). However, the database may also be part of a cloud environment or network that is communicatively coupled to the respective production data generation layer or control layer of the production plant so that the production data may be stored in the respective databases.

[0007] The system can generally be implemented in the form of any computing environment, in the form of any combination of hardware and / or software. In particular, the system can be considered as a computing framework that provides the functions described below. The corresponding computing framework can be implemented, for example, in the form of communicatively coupled computing hardware and / or software, which is constructed into corresponding functional layers, which provide the functions described below and can be accessed, for example, by other functional layers of the computing framework. Preferably, the computing framework is implemented as a microservice-based computing framework. Generally, a microservice-based framework refers to a variation of a service-oriented architecture, and applications are arranged as a set of loosely coupled services. In a microservice architecture (i.e., a framework), services are fine-grained and protocols are lightweight.

[0008] The abstraction layer is adapted to access each of a plurality of databases for retrieving production data from the respective database and for providing the retrieved data for further processing. In particular, the abstraction layer is configured to provide a conversion function that converts a command (in this case, specifically a data request) into a specific database command that allows access to the requested respective data and allows the requested data to be provided via the abstraction layer. Preferably, the abstraction layer refers to a stateless coordination programming interface. For example, the abstraction layer may be based on protocol buffers or gRPC remote procedure calls. It is further preferred that the abstraction layer is configured not only for coordination of data models as used by the model interface, but also for data discovery of the database system, i.e., for finding out which data is fully available or browsing a tree structure in a database.

[0009] The model interface is suitable for running an analysis workload that requires predetermined production data from one or more databases in a plurality of databases. In particular, the analysis workload refers to a process that allows processing (in particular analysis) of the required predetermined production data and provides an output based on the processing. For example, the analysis workload may refer to a production data model that uses production data to predict one or more results in the context of a production process. In addition, the corresponding analysis workload may also refer to an analysis of the corresponding production data to determine the corresponding production characteristics, for example, to determine the generation of Co2 during product production, the use of specific materials during product production, etc. In addition, the analysis workload may also refer to an optimization model that allows the production process to be optimized relative to one or more production parameters based on the required production data. The model interface is particularly suitable for enabling the abstraction layer to retrieve the required predetermined production data from one or more databases in a plurality of databases, and to provide the retrieved required predetermined production data to the analysis workload running on the model interface. Therefore, the model interface acts as an interface between the analysis workload and the abstraction layer, and therefore provides a further possibility of coordinating access to multiple databases. For example, the model interface may allow the data format and request format provided and / or required by the analysis workload to be converted into other formats required by one or more of the abstraction layer and / or storage devices. Preferably, the model interface is implemented as a gRPC service contract between the abstraction layer and the corresponding analysis workload.

[0010] In an embodiment, the abstraction layer further comprises a mapping layer, which includes production data locations on multiple databases to production data identifiers used by the model interface to indicate the required predetermined production data to the abstraction layer, wherein the abstraction layer is suitable for utilizing the mapping to retrieve the required predetermined production data. The mapping can be provided in any form of data structure that allows the production data location to be associated with the production data identifier utilized by the model interface. For example, the mapping can refer to a lookup table, a functional relationship, or a more complex structural relationship. Utilizing such a mapping allows production data access to be coordinated independently of the production data format or identifier utilized, for example, by the corresponding production plant or the database on which the corresponding production data is stored. In particular, the analysis workload only needs to provide indicators that indicate to the model interface which production data identifiers are required for the corresponding analysis workload, wherein, due to the mapping, the analysis workload or the user of the analysis workload does not have to know the specific location and / or data format of the required production data. Therefore, access to the corresponding predetermined production data becomes easier to implement.

[0011] In an embodiment, the abstraction layer includes a coordination model, wherein the coordination model is adapted to make requests and responses based on a programming analysis workload coordinated on multiple databases. The coordination model may refer to any model that allows the same data format and / or data structure to be utilized for requests and responses of the analysis layer. Therefore, the analysis workload can be programmed to utilize the coordinated requests and responses, respectively. Then, the coordination model can be adjusted to convert the coordinated requests and responses into the format and data type required by the corresponding database. For example, the coordination model can utilize corresponding mappings (e.g., lookup tables or functional relationships) to transform the coordinated requests and responses into corresponding requests and responses to the actual database. However, the coordination model can also utilize predetermined rules to convert the coordinated requests and responses. In particular, if the data format of the request and response for a specific database requires more information than the information provided by the coordinated request and response, the rule can determine how to provide such missing information, for example, by utilizing a predetermined value or by requesting the corresponding information from a user. Therefore, utilizing the corresponding coordination model allows the programming of the analysis workload to be further independent of the specific requirements of multiple databases.

[0012] In an embodiment, these analysis workloads may refer to active or passive analysis workloads, wherein active analysis workloads are adapted to run automatically on the model interface when not otherwise indicated, and passive analysis workloads are explicitly called by an external call service via an external command to run on the model interface. Typically, active analysis workloads may be configured to run automatically at predetermined time intervals, and are preferably implemented as a cronjob. In this context, an external call service refers to a service that is not part of the analysis workload itself but is located outside (i.e., external to) the analysis workload itself.

[0013] Preferably, the system further comprises a model management unit communicatively coupled to the calling service, wherein the model management unit is adapted to manage the calling of these passive analysis workloads on the model interface by causing the calling service to call the analysis workload based on predetermined rules. The corresponding predetermined rules for calling the analysis workload can be provided to the management unit, for example, associated with each corresponding passive model. These corresponding rules can refer to simple rules, for example, indicating the calling of the passive model as a specific time interval, such as every hour, every day or every week. However, the predetermined rules can also be more complex rules indicating that the passive model is called, for example, according to a predetermined event. Such events can refer to, for example, external events (such as specific user input) or internal events (for example, referring to the calling of another passive model). In addition, it is preferred that the model management unit is configured to allow registration, updating, viewing and deletion of analysis workloads, in particular, active analysis workloads.

[0014] Generally, providing a computing framework for active and passive analysis workloads as described above enables very efficient use of the corresponding computing resources. For example, it is not necessary to have multiple passive analysis workloads that should only run at scheduled times always run on the interface layer in order to achieve the predetermined functions. In fact, only the optional management unit must always utilize the computing resources in order to be communicatively coupled to the calling service, while the corresponding passive analysis workload will not run until it is explicitly called.

[0015] In an embodiment, the analytical workload is hosted based on containers. In particular, container-based hosting provides a runtime environment for the analytical workload that is encapsulated as an immutable infrastructure and therefore allows the use of many popular programming languages ​​since the only dependency is the Linux kernel. In addition, containerization allows for easier access and management of the corresponding analytical workloads. Preferably, these analytical workloads are containerized by running analytical workloads with the same data schedule within the same container environment. Containerizing analytical workloads with the same data schedule in the same container environment allows for easier and less computationally resource-intensive management of production data transfers from the database to the analytical workloads.

[0016] In an embodiment, the abstraction layer includes an access management layer, which is suitable for managing user access to one or more databases of a plurality of databases, so that for each of the one or more databases that the user can access, an access token of the user is generated that allows access to the corresponding database. In particular, it is preferred that the access management layer is suitable for verifying user access data of a specific database, such as a username and password, for example by verifying the user access data using the access management of the corresponding database. The access management layer then generates an access token based on the verified user access data and manages the user's access to the corresponding database via the access token. In addition, it is preferred that the access management layer is non-persistent, that is, the user access data is not stored persistently in any way. This has the following advantages: the security of access to the database can be greatly improved, especially relative to traditional database systems with outdated security management. In this context, an access token refers to a computing object that encapsulates the security identity of a process (in this case, in particular a data access process). The access token can indicate, for example, the identity of a user, information about a user group, information about user privileges, or information about a specific data process. Thus, providing a user with such an access token for each of one or more databases that the user is normally able to access enables the security of access to be improved and ensures that only users with valid security credentials can access potentially sensitive production data. Preferably, the abstraction layer is adapted to provide a super token for the user to provide access to the access management layer, wherein the super token is encrypted and includes all access tokens of the user and allows centralized access to the corresponding database. In particular, it is preferred that the super token refers to a wrapper of various access tokens of the user at the level of the corresponding database. In addition, it is preferred that the generated super token is encrypted before being provided to the user or the user client so that it is completely opaque to external access. Due to the additional verification layer, the use of such a super token enables the security of an already existing security system (e.g., an already existing security system of one or more of the databases) to be improved as well. For example, in some cases, the database refers to a traditional system that does not provide the same level of security as the current database system. In particular, in these cases, the super token enables the addition of another security layer that provides the current security requirements and therefore also strongly improves the security of the traditional database. Furthermore, it is preferred that all generated tokens or supertokens have an expiration date after which they are no longer valid and a new token or supertoken must be requested. This has the further advantage that unauthorized access based on a stolen token or supertoken is strongly limited in time and the security level can be easily adjusted, for example by adjusting the time period for which a token or supertoken is valid.

[0017] In an embodiment, the abstraction layer is adapted to access two or more of the plurality of databases in parallel so as to retrieve production data in parallel from at least two corresponding databases. This allows optimized access to the plurality of databases and retrieval of production data. Furthermore, preferably, the abstraction layer is configured to utilize a performance table to access production data in the corresponding databases, thereby achieving performance improvement.

[0018] In an embodiment, the abstraction layer is adapted to convert a legacy communication protocol of a database into a state-of-the-art communication protocol for communicating with the corresponding database.

[0019] In another aspect of the present invention, a user model interaction environment is provided, wherein the environment includes a user interface that allows a user to access a model interface of a system as claimed in any one of the preceding claims for providing, adjusting and / or controlling one or more analytical workloads. Optionally, the user model interaction environment also includes a system as claimed in any one of the preceding claims.

[0020] On the other hand, a user model interaction method is proposed, wherein the method includes providing a user interface that allows a user to access a model interface of a system as claimed in any of the preceding claims for providing, adjusting and / or controlling one or more analytical workloads.

[0021] In another aspect of the present invention, a method for accessing production data of one or more production plants is proposed, wherein the production data is stored in multiple databases, wherein the method includes: a) providing an abstract layer, which is suitable for accessing each of the multiple databases for retrieving production data from the corresponding database and for providing the retrieved data for further processing; b) providing a model interface, which is suitable for running an analytical workload that requires predetermined production data from one or more databases of the multiple databases; and c) enabling the abstract layer to retrieve the required predetermined production data from one or more databases of the multiple databases via the model interface, and provide the retrieved required predetermined production data to the analytical workload running on the model interface.

[0022] In another aspect of the present invention, a computer program product for accessing production data of one or more production plants is proposed, wherein the computer program product is adapted to cause the system as described above to execute the method as described above.

[0023] In another aspect of the invention, use of at least one of the system as described above, the method as described above, and the computer program product as described above for retrieving process production data of one or more production plants is proposed, in particular for compound optimization.

[0024] It shall be understood that the system as described above, the method as described above and the computer program product as described above have similar and / or identical preferred embodiments, in particular as defined in the dependent claims.

[0025] It shall be understood that a preferred embodiment of the present invention may also be any combination of the dependent claims or the above-described embodiments with the corresponding independent claim.

[0026] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In the attached picture:

[0028] Figure 1 A user model interaction environment is schematically and exemplarily shown, the user model interaction environment comprising a system for accessing production data of one or more production plants,

[0029] Figure 2 A flow chart exemplarily illustrating an embodiment of a method for accessing production data of one or more production plants is shown, and

[0030] Figures 3 to 7 A more detailed embodiment of a system for accessing production data of one or more production plants is shown schematically and exemplarily. DETAILED DESCRIPTION

[0031] Figure 1 Schematically and exemplarily, a user model interaction environment 100 is shown, which in this example comprises a plurality of user interfaces 110, 111, 112 and a system 120 for accessing production data of one or more production plants 130, 132, 134. In particular, the production plants 130, 132, 134 store the production data on one or more databases 131, 133, 135, which may optionally also be considered as part of the user interaction environment 100.

[0032] Typically, industrial plants 130, 132, 134 can refer to any technical infrastructure for industrial purposes. Industrial purposes can be the manufacture or processing of one or more industrial products, i.e., the manufacturing process or processing performed by the industrial plant. For example, industrial purposes can refer to the production of products. For example, the product can be any physical product, such as chemicals, biological products, medicines, food, beverages, textiles, metals, plastics or semiconductors. Additionally or alternatively, the product can even be a service product, such as electricity, heating, air conditioning, waste treatment (such as recycling), chemical treatment (such as decomposition or dissolution) or even incineration. Therefore, industrial plants 130, 132, 134 can refer to one or more of chemical plants, processing plants, pharmaceutical plants, fossil fuel processing facilities (such as oil and / or gas valves), refineries, petrochemical plants, cracking plants, etc. Industrial plants 130, 132, 134 can even refer to any one of breweries, incinerators or power plants. Industrial plants 130, 132, 134 can even refer to a combination of any of the examples given above.

[0033] In order to perform the production process, the industrial plant 130, 132, 134 includes a technical infrastructure that can be controlled by control parameters implemented into the technical infrastructure, such as by a process control system. The technical infrastructure may include equipment or process units, such as heat exchangers, towers such as fractionation towers, furnaces, reaction chambers, cracking units, storage tanks, precipitators, pipelines, chimneys, filters, valves, actuators, transformers, circuit breakers, machinery (e.g., heavy rotating equipment (such as turbines)), generators, pulverizers, compressors, fans, pumps, motors, etc. Any one or more. In addition, the industrial plant 130, 132, 134 typically includes a plurality of sensors that allow the measurement of operating parameters of the technical infrastructure. The measured operating parameters can then be stored in the corresponding databases 131, 133, 135 by the process control system with reference to the production data or as part of the production data, which can also be regarded as process database systems of the industrial plant 130, 132, 134. Further, the operating parameters can also be used by the process control system to control the production process in the industrial plant 130, 132, 134. The operating parameters measured by the sensors may relate to various process parameters and / or parameters associated with the equipment or process unit. For example, sensors may be used to measure process parameters such as flow rate in a pipeline, liquid level in a tank, temperature of a furnace, chemical composition of a gas, etc., and some sensors may be used to measure vibration of a turbine, speed of a fan, opening of a valve, corrosion of a pipeline, voltage across a transformer, etc. The differences between sensors may be based not only on the parameters they sense, but also on the sensing principles used by the respective sensors. Some examples of sensors based on the parameters sensed by the sensors may include: temperature sensors, pressure sensors, radiation sensors (such as light sensors), flow sensors, vibration sensors, displacement sensors, and chemical sensors (such as sensors for detecting specific substances (such as gases)). For example, examples of sensors with different sensing principles may be: piezoelectric sensors, piezoresistive sensors, thermocouples, impedance sensors (such as capacitive sensors and resistive sensors), etc. Sensors typically measure operating parameters in the form of time-dependent data values, i.e., data values ​​associated with the specific time at which the sensors measure these operating parameters. It is common to store these time-dependent data values ​​measured by the sensors in the form of time series data sets on databases 131, 133, 135.

[0034] Furthermore, in addition to the operating parameters measured in the form of time series data sets, event-based operating data can also be determined, for example, by sensors of the process control system (more generally by the process control system) and stored on the databases 131, 133, 135. Event-based operating data refers to operating data associated with a specific event, for example associated with a failure of a part of the technical equipment of the industrial plant 130, 132, 134. This data can be provided in any format suitable for the respective event, for example, it can refer to an error code or process protocol for a specific time frame. Similarly, such event-based operating data can refer to production data or be part of production data. The database 131, 133, 135 can refer, for example, to a storage device comprising dedicated hardware and / or software for storing production data. However, the database 131, 133, 135 can also refer to a general storage device or any other computing system that allows in particular to store production data.

[0035] Typically, the industrial plants 130, 132, 134 may be integrated into an enterprise control system for managing and controlling the production performed by the industrial plants 130, 132, 134. In order to manage and control the industrial plants 130, 132, 134, it is typically desirable to retrieve production data from the databases 131, 133, 135 and utilize the retrieved production data in analytical workloads that may be suitable not only for analysis but also for providing control signals for controlling the production processes in the industrial plants 130, 132, 134. In particular, the analytical workload may refer to or be part of a dedicated and more complex management and control system (such as an enterprise control system). In particular, in many practical applications, the computational framework for managing, controlling and retrieving production data on the databases 131, 133, 135 refers to a conventional system that is not suitable for more complex processing and analysis of the corresponding data.

[0036] In order to access the databases 131, 133, 135 to retrieve production data, the user model interaction environment 100 includes a system 120 for accessing production data on multiple databases 131, 133, 135. The system 120 can be implemented, for example, in the form of a computing framework in a cloud-based or server-based computing architecture. However, the system 120 can also be implemented as any kind of hardware and / or software that provides the functions described below. In particular, the system 120 includes an abstraction layer 121, which is configured to access each of the multiple databases 131, 133, 135 for retrieving production data from the corresponding database and further for providing the retrieved data for further processing. In particular, the abstraction layer is provided with all necessary communication protocols that allow the abstraction layer to access the corresponding databases 131, 133, 135, wherein any layer or program that interacts with the abstraction layer for retrieving production data from one of the databases 131, 133, 135 can do so without any knowledge or information about the corresponding specific protocol used by the corresponding database 131, 133, 135.

[0037] Further, the system includes a model interface 122, which is suitable for running an analytical workload that requires predetermined production data from one or more of the multiple databases 131, 133, 135. The analytical workload may refer to any kind of program or analytical tool that utilizes stored production data from one or more of the production plants 130, 132, 134. For example, the analytical workload may refer to a model that allows the calculation of the generated CO2 during the production of a product in one or more of the production plants 130, 132, 134. The model interface is suitable for enabling the abstraction layer to retrieve the predetermined production data required for the analytical workload from one or more of the multiple databases 131, 133, 135, and provide the retrieved required predetermined production data to the corresponding analytical workload running on the model interface. Therefore, the model interface can serve as a runtime environment for one or more analytical workloads, and further serves as an interface between the analytical workload and the abstraction layer. Then, a user or another system can access the model interface 122 using the user interface 110, 111, 112, in particular, for providing, adjusting and / or controlling one or more of these analytical workloads. For example, a user may upload a new analytical workload to the model interface 122 using the user interface 112. In addition, a user may also utilize a user interface (such as the user interface 112) to update or otherwise adjust one of the analytical workloads running on the model interface 122. Further, the results of the analytical workload (e.g., analysis results or model predictions) may also be provided from the analytical workload running on the model interface 122 to one or more of the user interfaces 110, 111, 112 so that they can be provided to a user or another processing system.

[0038] Figure 2 A method 200 for accessing production data of one or more production plants is shown schematically and exemplarily, wherein the method can be implemented as a computer-implemented method, for example by Figure 1 The method comprises: in step 210, providing an abstraction layer, which is suitable for accessing each of a plurality of databases for retrieving production data from the corresponding database and for providing the retrieved data for further processing. Further, the method comprises: in step 220, providing a model interface, which is suitable for running an analytical workload that requires predetermined production data from one or more of the plurality of databases. In step 230, the method comprises: in particular, causing the abstraction layer to retrieve the required predetermined production data from one or more of the plurality of databases via the model interface, and providing the retrieved required predetermined production data to the analytical workload running on the model interface.

[0039] Further details of a preferred embodiment of a system for accessing production data will be described below. In general, the present invention relates to the idea of ​​"implementation through abstraction", whereby the idea is created to enable modelers to access legacy source systems (e.g., databases) without them actually noticing that they are still using these systems. According to the invention described above, this can be achieved by providing an abstraction layer between the modeler and the legacy system. Figure 3 A schematic diagram of an exemplary framework of this principle of the present invention is shown. The extent to which the traditional layer is abstracted may involve a set of characteristics of the abstraction layer and determine the "thickness" of the abstraction layer. For example, the abstraction layer can be configured to provide a single endpoint for accessing production data in all systems (particularly, databases) behind the layer, thereby reducing the number of endpoints that the modeler must use. Further, by providing a model interface, a data model for data consumers (e.g., analytical workloads) can also be provided as coordinated as possible, especially with respect to production data. In addition, it is preferred that the abstraction layer utilizes a mapping layer. Typically, different systems use different data formats with different data identification formats and different semantics (e.g., the meaning of field names). In this case, the unification of these data formats is achieved using a mapping layer. In particular, the mapping layer is configured to contain a mapping between identifiers before and after the abstraction layer. The data in the mapping layer can be maintained by the modeler, and thus 100% abstraction of the backend source system can be achieved even at the identification level.

[0040] The present invention thus has the following advantages: Since no replication is required between systems, the "latest" version of the production data is always available to data consumers. Further, since no additional stateful backend is required for storing the data, the infrastructure requirements are greatly reduced, and the cost of ownership is directly reduced if, for example, a thick stateful mapping layer is utilized as described above. In addition, the database and associated systems do not have to tolerate the load of continuous data transfers, for example to a central or cloud database, but rather the load of model queries. This is a particularly powerful way to reduce unnecessary load for systems that do not contain a large amount of data of interest to the modeler.

[0041] Typically, an abstraction layer is provided so that the abstract application programming interface (API) consumer has minimal dependence on the traditional system at the protocol and semantic level. In addition, the abstraction layer API can be easily extended. Further, the traditional system can be migrated with minimal impact on the data consumer, and a failover strategy can be implemented. The abstraction layer can be further configured to optimize requests to reduce the load on the traditional system. In particular, another advantage of the system being implemented as an embodiment of a microservice-based gRPC framework is that all microservices on the corresponding computing cluster (e.g., forming an abstraction layer) can be configured to share a common programming language-independent data model. For example, the translator of the provided gRPC framework can be used to convert predefined data models into other programming languages. This allows the provided model interface and / or analysis workload to be implemented in all modern programming languages.

[0042] In a preferred embodiment, the model interface is configured to distinguish between so-called "active" models and so-called "passive" models, wherein "active" models specifically refer to models that wake up themselves and are called on a periodic basis for each timed task, while "passive" models must be called via external calls. For passive models, a model type can refer to an application programming interface, and external services can be provided to call the model with appropriate data. Preferably, the inputs, outputs and parameters of this model will be persisted. Figure 4 and Figure 5 Schematic diagrams of exemplary computing frameworks that can provide and run passive and active analytical workloads (eg, models) according to the present invention are shown, respectively.

[0043] For active models, it is preferred to have one model per container, which eliminates the need to maintain the model's inputs, outputs, and parameters in external systems. Instead of a dedicated container for each model, there can also be dedicated containers started by a cron job that run all models for this interval in sequence, for example, one container for hourly models, one container for daily models, and one container for weekly models.

[0044] For some use cases, even passive models may be a bit too heavy. Especially for model types that are only used by a very small number of models, hosting the entire container may be a bit too resource-intensive. In this case, it is preferred that the model interface is configured to provide another subclass of passive models (called "script-based models"). These subclasses can be implemented as python scripts that can be persisted in the database and called directly using the call service.

[0045] Since passive models must be called externally, preferably some external software component ensures that each model is called according to the configured cycle time, knows which models exist, and which models require which data and under which endpoint. Preferably, for this task, a model management unit is provided, which is configured accordingly and communicates with a call service for calling the corresponding model.

[0046] Typically, an abstraction layer that provides an interface to the production data of a database has special relevance in terms of security, since it is the central point of access for reading and writing data from the corresponding database. In a preferred embodiment, the abstraction layer includes an additional access control layer based on an external trust source (e.g., Azure AD), which assigns the abstraction layer itself full access rights to the underlying database system. In this case, the corresponding analytical workload and the access control layer are responsible for the corresponding authentication and authorization of users. Therefore, additional users and groups need to be created and maintained. In this embodiment, the already existing (local AD) user tokens and functional accounts of the database system itself cannot be used. This can reduce the adoption rate of the corresponding analytical workload. However, the huge advantage is that all best practices in terms of security can be easily implemented by the access control layer.

[0047] In another preferred embodiment, existing authentication and authorization mechanisms (e.g., user tokens) are reused, for example, by passing the credentials of the analytical workload user. Therefore, the analytical workload itself does not have to provide any access rights. Further, there is no need to maintain more access control layers, but as a disadvantage of this approach, the system is based on multiple authority authorities, which may act as trusted authority authorities to authenticate users. Additionally, the abstraction layer must support and securely encapsulate some outdated traditional authentication mechanisms.

[0048] Preferably, a super token is utilized that encapsulates multiple sub-tokens, which are used to authenticate against corresponding database systems, such as legacy systems. Figure 6A schematic diagram of an exemplary computing framework and the contents of a super token according to the present invention is shown. These sub-tokens are included as part of the super token. In particular, it is preferred that a unique backend system (particularly a database) identifier is provided as part of the super token, wherein the value of the identifier refers to a token that authorizes access to the associated backend system. Therefore, there are various reasons for obtaining or refreshing a super token, such as expiration of a token in the abstraction layer or expiration of a token in one of the backend systems. In both cases, a brand new super token can be generated for the user that includes brand new sub-tokens for all backend systems.

[0049] Figure 7 An exemplary detailed example of the application of the present invention is shown. In this example, the data consumer wants to calculate the CO2 footprint of the entire production site, wherein the production site contains multiple distributed production data databases, such as historian databases, which contain the production data necessary to calculate the footprint. Typically, each database system may have a different data model and interface. Therefore, to calculate the CO2 footprint of the production site, each of these different database system requirements must be handled. Providing an abstraction layer as described in detail above effectively improves this situation. In particular, it is preferred that the abstraction layer is configured to accept aggregate requests for multiple database systems and distribute requests between multiple database systems (e.g., backend source historian databases) in a parallel manner. In addition, it is preferred that the abstraction layer is suitable for converting all responses to a common shared data model once the database system responds. From the perspective of the data consumer (e.g., an analytical workload), the data looks exactly the same regardless of which source system the data originates from. Therefore, this greatly simplifies creating analysis on top of this data.

[0050] Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure, and the appended claims.

[0051] For the processes and methods disclosed herein, the operations performed in the processes and methods may be implemented in different orders. In addition, the operations outlined are provided only as examples, and some of the operations may be optional, may be combined into fewer steps and operations, may be supplemented with more operations, or may be expanded into more operations without departing from the essence of the disclosed embodiments.

[0052] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality.

[0053] A single unit or device may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0054] The processes performed by one or more units or devices, such as providing an abstraction layer of a model interface, etc., may be performed by any other number of units or devices. These processes may be implemented as program code means of a computer program and / or dedicated hardware.

[0055] The computer program product may be stored / distributed on a suitable medium, such as an optical storage medium or a solid-state medium provided together with or as a part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

[0056] Any unit described herein may be a processing unit as part of a classical computing system. The processing unit may include a general-purpose processor, and may also include a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other dedicated circuit. Any memory may be a physical system memory, which may be volatile, non-volatile, or some combination of the two. The term "memory" may include any computer-readable storage medium, such as a non-volatile mass storage device. If the computing system is distributed, the processing and / or storage capabilities may also be distributed. The computing system may include multiple structures as "executable components". The term "executable component" is a structure that is fully understood in the computing field as a structure that can be software, hardware, or a combination thereof. For example, when implemented in software, a person of ordinary skill in the art will understand that the structure of the executable component may include software objects, routines, methods, etc. that can be executed on the computing system. This may include executable components in the computing system stack or on a computer-readable storage medium. The structure of the executable component may exist on a computer-readable medium so that when interpreted by one or more processors of the computing system (e.g., by a processor thread), the computing system performs a function. Such a structure may be directly computer-readable by a processor, for example, as in the case where the executable component is binary, or it may be constructed to be interpretable and / or compiled, for example, whether in a single level or multiple levels, thereby generating such binary that can be directly interpreted by a processor. In other cases, the structure may be hard-coded or hard-wired logic gates that are implemented exclusively or almost exclusively in hardware, such as in a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other dedicated circuit. Therefore, the term "executable component" is a term for a structure that is well known to those of ordinary skill in the field of computing, whether implemented in software, hardware, or a combination. Any embodiment herein is described with reference to actions performed by one or more processing units of a computing system. If such actions are implemented in software, one or more processors direct the operation of the computing system in response to having executed the computer-executable instructions that constitute the executable component. The computing system may also include a communication channel that allows the computing system to communicate with other computing systems, such as through a network. "Network" is defined as one or more data links that enable electronic data to be transmitted between computing systems and / or modules and / or other electronic devices. When information is transferred or provided to a computing system over a network or another communications connection (e.g., hardwired, wireless, or a combination of hardwired or wireless), the computing system properly views the connection as a transmission medium. Transmission media may include networks and / or data links that may be used to carry desired program code means in the form of computer-executable instructions or data structures and may be accessed by general purpose computing systems or special purpose computing systems or a combination thereof.Although not all computing systems require a user interface, in some embodiments, a computing system includes a user interface system for interacting with a user. The user interface serves as an input or output mechanism for the user, for example, via a display.

[0057] Those skilled in the art will appreciate that at least part of the present invention can be practiced in a network computing environment with various types of computing system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, pagers, routers, switches, data centers, wearable devices (such as glasses), etc. The present invention can also be practiced in a distributed system environment, where, for example, a local computing system and a remote computing system linked by a network by a hardwired data link, a wireless data link, or a combination of hardwired and wireless data links perform tasks together. In a distributed system environment, program modules can be located in both local and remote memory storage devices.

[0058] Those skilled in the art will also appreciate that at least part of the present invention can be practiced in a cloud computing environment. The cloud computing environment can be distributed, but this is not necessary. When the cloud computing environment is distributed, it can be distributed in multiple countries within an organization and / or have components across multiple organizations. In this specification and the appended claims, "cloud computing" is defined as a model for implementing on-demand network access to a shared pool of configurable computing resources (such as networks, servers, storage devices, applications and services). The definition of "cloud computing" is not limited to any of the other numerous advantages that can be obtained from this model when deployed. The computing system of the accompanying drawings includes various components or functional blocks that can implement various embodiments disclosed herein as explained. Various components or functional blocks can be implemented on a local computing system, or can be implemented on a distributed computing system that includes elements residing in the cloud or implementing various aspects of cloud computing. Various components or functional blocks can be implemented as software, hardware, or a combination of software and hardware. The computing system shown in the figure can include more or fewer components than those shown in the figure, and some of these components can be combined as needed according to the situation.

[0059] Any reference signs in the claims should not be construed as limiting the scope.

[0060] The present invention relates to a system for accessing production data of a production plant. The production data is stored on a plurality of databases. An abstraction layer is adapted to access each of the databases for retrieving the production data from the database and for providing the retrieved data for further processing. A model interface is adapted to run an analytical workload requiring production data from the databases, and is further adapted to cause the abstraction layer to retrieve the required predetermined production data from the databases and provide the retrieved required predetermined production data to the analytical workload running on the model interface. This allows access to any type of production data stored on a plurality of databases from anywhere and at any scale while requiring less computing resources.

Claims

1. A system for accessing production data of one or more production plants (130, 132, 134), in, The production data is stored in a plurality of databases (131, 133, 135), wherein the system (120) comprises: an abstraction layer (121) adapted to access each of the plurality of databases (131, 133, 135) for retrieving production data from the respective database and for providing the retrieved data for further processing; and A model interface (122) adapted to run an analytical workload requiring predetermined production data from one or more of the plurality of databases (131, 133, 135), and further adapted to enable the abstraction layer (121) to retrieve the required predetermined production data from one or more of the plurality of databases (131, 133, 135) and provide the retrieved required predetermined production data to the analytical workload running on the model interface.

2. The system according to claim 1, in, The abstraction layer (121) further comprises a mapping layer, which comprises production data locations on the plurality of databases (131, 133, 135) to production data identifiers used by the model interface (122) to indicate required predetermined production data to the abstraction layer (121), wherein the abstraction layer (121) is adapted to retrieve the required predetermined production data using the mapping.

3. The system according to any one of claims 1 and 2, in, The abstraction layer (121) includes a coordination model, wherein the coordination model is adapted to enable requests and responses to be based on a programmatic analysis workload coordinated across the plurality of databases (131, 133, 135).

4. A system according to any one of the preceding claims, in, These analysis workloads may refer to active or passive analysis workloads, wherein active analysis workloads are adapted to run automatically on the model interface (122) when not otherwise instructed, and passive analysis workloads are explicitly invoked by an external call service via external commands to run on the model interface (122).

5. The system according to claim 4, in, The system further includes a model management unit communicatively coupled to the invocation service, wherein the model management unit is adapted to manage invocation of the passive analysis workloads on the model interface (122) by causing the invocation service to invoke the analysis workload based on predetermined rules.

6. A system according to any one of the preceding claims, in, These analytical workloads are hosted on containers.

7. The system according to claim 6, in, These analytical workloads are containerized by running the analytical workloads with the same data schedule within the same container environment.

8. A system according to any one of the preceding claims, in, The abstraction layer (121) includes an access management layer, which is suitable for managing user access to one or more databases among the multiple databases (131, 133, 135), so that for each of the one or more databases that the user can access, an access token for the user is generated that allows access to the corresponding database.

9. The system according to claim 8, in, The abstraction layer (121) is adapted to provide a super token for a user to provide access to the access management layer, wherein the super token is encrypted and includes all access tokens of the user and allows centralized access to the corresponding databases (131, 133, 135).

10. A user model interaction environment, in, The environment includes: A user interface allowing a user to access a model interface (122) of a system as claimed in any one of the preceding claims for providing, adjusting and / or controlling one or more analytical workloads.

11. A method for accessing production data of one or more production plants (130, 132, 134), in, The production data is stored in a plurality of databases (131, 133, 135), wherein the method (200) comprises: providing (210) an abstraction layer (121) adapted to access each of the plurality of databases (131, 133, 135) for retrieving production data from the respective database and for providing the retrieved data for further processing; providing (220) a model interface (122) adapted to run an analytical workload requiring predetermined production data from one or more of the plurality of databases (131, 133, 135); and The abstract layer (121) is enabled (230) to retrieve required predetermined production data from one or more databases among the plurality of databases (131, 133, 135) via the model interface (122), and the retrieved required predetermined production data is provided to an analysis workload running on the model interface (122).

12. A computer program product for accessing production data of one or more production plants (130, 132, 134), in, The computer program product is adapted to cause the system according to claim 1 to perform the method according to claim 11.

13. Use of at least one of the system according to any one of claims 1 to 9, the method according to claim 11, and the computer program product according to claim 12 for retrieving process production data of one or more production plants (130, 132, 134), in particular for compound optimization.

Images