Computer-implemented orchestration instance and method for the automated generation of automation for a technical installation

Abstract

The invention relates to a method for automatically generating automation for a technical installation, in particular a manufacturing or process installation, which technical installation comprises a plurality of individual technical modules, by means of a computer-implemented orchestration service, the method comprising: a) subdividing a basic flow diagram, which comprises a description of a manufacturing and / or process engineering process to be implemented in the technical installation, according to the individual technical modules, b) extending the subdivided basic flow diagram with semantically unique capabilities, which the technical modules must each have in order to implement the manufacturing and / or process engineering process, in order to generate an abstract orchestration specification (5), c) with the incorporation of MTP files, formed according to the VDI / VDE / NAMUR 2658 standard valid at the time of the present application, said files comprising a semantically unique description of types of technical modules available in the technical installation, comparing the semantically unique capabilities from the abstract orchestration specification (5) with the descriptions of the available types from the MTP files.

Description

[0001] Description

[0002] Computer-implemented orchestration instance and method for the automated generation of automation for a technical plant

[0003] The invention relates to a method for the automated generation of automation for a technical plant, in particular a manufacturing or process plant, which technical plant comprises a plurality of individual technical modules, by means of a computer-implemented orchestration service. The invention further relates to a method for generating an abstract orchestration instruction by means of a computer-implemented orchestration service. The invention also relates to a computer-implemented orchestration service. Furthermore, the invention relates to a technical plant with a computer-implemented orchestration service. Finally, the invention relates to a control system for a technical plant, which includes an operator station client and an operator station server for operating and monitoring the technical plant.

[0004] For approximately five years, the orchestration of modular plants has been the subject of research, refinement, and improvement. From a practical perspective, some of these research findings have already been incorporated into current product solutions for Process Orchestration Layers (POLs). The distinction between type-based and instance-based engineering is also well-established. However, the engineering process currently requires manual execution and in-depth knowledge of the specific POL solution being used.

[0005] Document WO 2016 / 074730 A1 describes a method for creating a modular technical system using self-description information from the modules. This method is based on online self-description information for the individual modules. However, this information is typically not available (online) during the orchestration process of a modular system, as planning is carried out offline based on static type description information such as the Module Type Package (MTP) (see the draft standard "VDI / VDE / NAMUR 2658" published by the Association of German Engineers (VDI) on January 4, 2018). EP 2 866 105 A1 describes a basic technology that can be used to implement so-called service capsules.

[0006] EP 3 712 730 A1 describes a method for the automated orchestration of multiple technical modules of a process plant. This involves first creating superservices and then mapping them to a process recipe to be implemented. However, this sequence of steps has proven to be disadvantageous.

[0007] The invention is based on the objective of providing a method for generating automation for a technical plant that can be carried out automatically and efficiently.

[0008] This problem is solved by a method for the automated generation of automation for a technical plant according to claim 1. Furthermore, the problem is solved by a method for generating an abstract orchestration instruction using a computer-implemented orchestration service according to claim 6. The invention also relates to a method for operating a technical plant, a computer-implemented orchestration service, a technical plant, and a control system for a technical plant. Advantageous embodiments are the subject of the dependent claims.

[0009] An inventive method for the automated generation of automation for a technical plant, in particular a manufacturing or process plant, which technical plant comprises a plurality of individual technical modules, by means of a computer-implemented orchestration service comprises the following steps: a) Subdividing a basic flow diagram, which includes a description of a manufacturing and / or process engineering process to be implemented in the technical plant, according to the individual technical modules, b) Extending the subdivided basic flow diagram with semantically unambiguous capabilities that the technical modules must each possess to implement the manufacturing and / or process engineering process in order to generate an abstract orchestration instruction, c) Including MTP files created in accordance with the standard VDI / VDE / NAMUR 2658, which is valid at the time of the present patent application,which include a semantically unambiguous description of the types of technical modules available in the technical system, comparison of the semantically unambiguous capabilities from the abstract orchestration rule with the descriptions of the available types from the MTP files, d) If a match is found during the comparison, assignment of the respective type of technical module to the respective semantically unambiguous capability in order to generate a type-specific orchestration rule, e) Automated determination of the technical modules available in the technical system and assignment of each of these technical modules to a type of technical module contained in the type-specific orchestration rule in order to generate the automation as an instance-specific orchestration rule.

[0010] Automation encompasses various process steps, such as switching devices on and off, controlling process parameters like temperature, pressure, or flow rate, monitoring sensor data, and acquiring operational data from the process plant. Automation includes at least the parameterization of the plant's components and the interaction of these components with one another. Automation typically refers to a specific production process to be carried out within the technical plant. A production process, in this context, refers to a series of steps or activities performed to transform raw materials or components into a finished product within the process plant. The production process can include various phases, such as design, raw material procurement, manufacturing, assembly, and packaging.

[0011] A process plant is a technical installation from the process industry, such as a chemical, pharmaceutical, petrochemical, or food and beverage plant. This includes any installation from the manufacturing industry, such as factories where, for example, cars or goods of all kinds are produced. Technical installations suitable for carrying out the inventive process can also originate from the energy generation sector. Wind turbines, solar power plants, or power stations for energy generation are likewise encompassed by the term "technical installation."

[0012] These systems each have a control system or at least a computer-aided module for controlling and regulating the ongoing process or production. Part of the control system or control module, or of the technical system, is at least a database or archive in which historical data is stored.

[0013] A technical module is understood to be a self-contained technical unit that can be integrated into a higher-level control system. Such a technical module could, for example, be a group of several measuring points or a larger component of an industrial plant. However, the technical module does not necessarily have to originate from industrial plants; it could also be, for instance, an engine module from a car, a ship, or similar equipment. The technical module is designed to function independently of other components of the technical plant, such as other technical modules, although it can, of course, interact with these other components / modules during operation.

[0014] The invention starts with a basic flow diagram as the basis for generating the automation. This basic flow diagram is already available at the beginning of the inventive method. A basic flow diagram is a graphical representation of a process or technical system that shows individual process steps and process components. It represents a simplified diagram that illustrates the flow of materials, energy, or information within a system. A basic flow diagram depicts the connections and interactions between the various elements of a system.

[0015] The basic flow diagram is first subdivided into individual technical modules. Then, requirement signatures in the form of PEA roles (PEA = Process Equipment Assembly) for each technical module are specified. A PEA role describes the capabilities a technical module must possess, using semantically unambiguous service, procedure, and procedure parameter types. These unambiguous types are managed in a service type pool for the technical plant. Annotating the basic flow diagram results in the extended basic flow diagram or the abstract orchestration specification.

[0016] The semantic information from the extended basic flow diagram is then used for type transformation. This step involves a PEA type pool implemented in the technical plant, which manages all available technical modules (whether physically present or on a marketplace). The services, procedures, and procedure parameters of the technical modules were previously assigned to the service, procedure, and procedure parameter types of the service type pool.

[0017] Using functional ontology, i.e., semantic uniqueness, it is possible to find suitable types of technical modules from the PEA type pool for each PEA role defined in the abstract orchestration rule. This effectively automates the process of comparing individual properties, which was previously performed manually by an operator / project manager.

[0018] In a subsequent step, the technical modules actually available in the technical system—that is, the physically present and usable modules—are assigned to the types of technical modules contained in the type-specific orchestration rule, thereby generating an instance-specific orchestration rule. Preferably, the automated determination of the technical modules available in the technical system is carried out using a real-time locating system (RTLS). Using such a real-time locating system allows the precise location of technical modules within the technical system to be determined in real time, enabling improved management of available resources and simple, automated assignment of these resources (technical modules) in the type-based orchestration rule.

[0019] The real-time localization system determines the positions of the technical modules within the technical system, preferably by means of wired or wireless transmission of communication telegrams to the technical modules and by comparing the transit times of the transmitted communication telegrams. The real-time localization system transmits communication telegrams from various transmitters to the respective technical modules and determines the positions of the technical modules within the technical system by comparing the transit times of the communication telegrams (given the known location of the transmitters).

[0020] In a preferred further development of the invention, the technical modules available in the technical system are identified using network identification within a communication network of the technical system. A communication network for technical systems is a system that, among other things, connects the technical modules to enable the exchange of information and data between the technical modules and other components of the technical system. It serves to facilitate communication, control, and monitoring of the technical system. By applying this method, it is possible to easily and automatically determine which technical modules are registered as communication participants in the communication network and can be considered as potential instances for orchestration. The Simple Network Management Protocol (SNMP) is preferably used for network identification.This is a network protocol used in computer networks to monitor, manage, and control network devices such as routers, switches, servers, printers, and other equipment. The SNMP protocol allows information about the health and performance of network devices to be collected by using an agent on each device (including each technical module). The agent collects data and makes it available in a standardized format. A network management system (NMS) can retrieve and analyze this data to detect network problems, gather performance statistics, and make configuration changes.

[0021] The previously formulated problem is also solved by a method for generating an abstract orchestration rule using a computer-implemented orchestration service, which comprises the following steps: a) Starting from an instance-specific orchestration rule used for the automation of a technical plant, in particular a manufacturing or process plant, wherein the technical plant comprises a plurality of individual technical modules, abstracting the instance-specific orchestration rule to a type-specific orchestration rule, including the technical modules available in the technical plant; b) Abstracting the type-based orchestration rule to an abstract orchestration rule, including MTP files formed according to the VDI / VDE / NAMUR 2658 standard, which is valid at the time of the present patent application.which include a semantically unambiguous description of the types of technical modules available in the technical plant.

[0022] In contrast to the previously described method, which represents a kind of top-down approach, the method described here starts with an existing plant automation system that has proven effective. It is therefore a bottom-up approach. The starting point of the bottom-up workflow is an experimentally assembled technical system consisting of several instances of technical modules. These have been directly integrated into a process orchestration layer, and their services are managed via a recipe or a sequence of processes.

[0023] Within the framework of an instance-inverse transformation, the instance-specific orchestration rule is abstracted to the type-specific orchestration rule using the function ontology. This involves creating a database query that determines the module type corresponding to the module instance. To reconstruct the extended basic flow diagram, only the services, procedures, and procedure parameters used by the module types are created and replaced with the corresponding service, procedure, and procedure parameter types. This reduces the experimental approach to the abstract orchestration rule. The bottom-up approach serves to abstract an (experimentally) assembled plant configuration and reduce it to an abstract orchestration rule.

[0024] This abstract orchestration rule can then be used to automatically create a new instance-specific orchestration rule adapted to changed conditions in the technical system, i.e., an automation.

[0025] The previously formulated task is also solved by a method for operating a technical plant, in particular a manufacturing or process plant, which technical plant comprises a plurality of individual technical modules, including automation that has been generated as explained above.

[0026] Furthermore, the task is solved by a computer-implemented orchestration service trained to perform a procedure as previously explained.

[0027] Furthermore, the task is solved by a technical system with such a computer-implemented orchestration service.

[0028] Furthermore, the task is solved by a control system for a technical plant, which has an operator station client and an operator station server for operating and monitoring the technical plant, with the orchestration service described above being computer-implemented on the operator station server.

[0029] In this context, an "Operator Station Server" is understood to be a server that centrally collects data from an operator control and monitoring system, as well as typically alarm and measurement data archives from the control system of the technical plant, and makes this data available to users. The Operator Station Server usually establishes a communication link to the automation systems of the technical plant and forwards data from the technical plant to so-called clients, which are used to operate and monitor the operation of the individual functional elements of the technical plant. The Operator Station Server can have client functions to access the data (archives, messages, tags, variables) of other Operator Station Servers. This allows images of the operation of the technical plant on the Operator Station Server to be combined with variables from other Operator Station Servers (server-to-server communication).The Operator Station Server can be, but is not limited to, a SIMATIC PCS 7 Industrial Workstation Server from SIEMENS.

[0030] The properties, features, and advantages of this invention described above, as well as the manner in which they are achieved, will become clearer and more readily understandable in connection with the following description of exemplary embodiments, which are explained in more detail in conjunction with the drawings. The drawings show:

[0031] FIG 1 shows a schematic representation of a method according to the invention;

[0032] FIG 2 shows a schematic representation of functional ontologies used within the scope of the invention;

[0033] FIG 3 shows a first method for determining technical modules available in a technical plant; and FIG 4 shows a second method for determining technical modules available in a technical plant.

[0034] Figure 1 schematically illustrates the process of a method according to the invention for generating automation for a technical plant. The first column, S1, denotes module management, the second column, S2, an orchestration sequence, the third column, S3, a type of orchestration rule, and the fourth column, S4, the technical implementations of the automation generation process. A first row, Z1, describes the procedure during a project planning phase, the so-called engineering of the technical plant. A second row, Z2, describes the procedure during the operational phase of the technical plant, i.e., during operation.

[0035] Figure 1 illustrates that orchestration requires an interplay between module management functionality, the actual orchestration process (the so-called workflow), and information management for various orchestration rules. Furthermore, orchestration is divided into an engineering phase and a runtime phase.

[0036] The computer-implemented module management functionalities manage three different information pools: A Service Type Pool 1 comprises various service types as well as their procedure and parameter types. These serve for the semantically unambiguous classification of services, procedures, and parameters. A Module Type Pool 2 comprises all the different types of technical modules currently managed in the system. Each module type is semantically uniquely described by a Module Type Package (MTP). The services, procedures, and parameters contained in the module type are assigned corresponding types from Service Type Pool 1 for semantically unambiguous description. A Module Instance Pool 3 comprises all instances of technical modules currently managed in the system. Each module instance is linked to a module type and extended with necessary instance information, such as the IP addresses of the OPC UA endpoints or certificates.The allocation process will be discussed in more detail below. The starting point for the top-down approach is an existing extended basic flow diagram 4. This diagram describes the process to be implemented (the process engineering process, which is to be implemented by suitable module instances). The extended basic flow diagram 4 describes all process steps to be carried out, enriched with semantic characteristics from the service type pool 1. In doing so, so-called module roles are defined. These module roles have a set of service, procedure, and parameter types and thus represent the functional requirement signature, i.e., the minimum requirements for a technical module to be used. Each module role must subsequently be filled by a suitable module instance. The set of all module roles is summarized as an abstract orchestration rule 5.

[0037] The following type transformation 6 adopts the abstract orchestration rule and describes how suitable module types are derived from a module role and its functional requirement signature. For this purpose, the semantically unambiguous characteristics of the module types and the module roles are compared. If there is a match, a module type is assigned to the corresponding module role. The result is the type-specific orchestration rule 7.

[0038] In the subsequent instance transformation 8, the type-specific orchestration rule 7 is applied, and the module types assigned to each module role are used to determine the set of all available matching module instances. From this set, a specific instance is selected to implement the role. Thus, each module role is assigned exactly one module instance. This results in the instance-specific orchestration rule 9.

[0039] This is then loaded into the runtime Z2 of the orchestration system, and the execution 10 of the technical system is carried out using an executable orchestration rule 11 generated from the instance-specific orchestration rule 9. Functional ontologies 12, which are explained in more detail with reference to FIG. 2, are used in this process. The automated determination 13, 14 of the technical modules available in the technical system is explained with reference to FIG. 3 and FIG. 4.

[0040] The functional ontology is separated into three sub-ontologies 15, 16, and 17 and related by an alignment ontology. The Resource Description Framework (RDF) was used for this purpose. The module instance ontology 15 serves to assign multiple module instances 22 to a module type 23 and is considered during the instance transformation 8. The module type ontology 16 manages module type packages 18 and the services 19 described therein, including their procedures 20 and parameters 21. The service type ontology 17 classifies service types 24, procedure types 25, and parameter types 26. Furthermore, hierarchies of service types 24 can also be represented. The alignment ontology 27a, 27b, 27c, 27d links the three sub-ontologies 15, 16, 17.

[0041] An equivalence relationship is introduced between the entities MTP and module type 23 in the module instance ontology 15 and the module type ontology 16. "Realizes" relationships are introduced between service 19, procedure 20, and procedure parameters 21 in the service type ontology 17 and the module type ontology 16.

[0042] The functional ontology is used to support type and instance transformation. In the top-down approach, the process design, which uses the service type ontology 17, can be matched with suitable PEA types via appropriate SPARQL queries (= type transformation). In the instance transformation, the relationships of the module instance ontology 15 are used to determine all existing module instances 22 of the module types 22 specified in the type-based orchestration rule 7. An instance from this set is selected to finalize the instance-based orchestration rule 9 for execution. In the bottom-up approach, the corresponding relationships between the aforementioned entities are interpreted in reverse. FIG 3 illustrates the determination of available module instances 22 based on RTLS mechanisms.RTLS systems determine both location and identification information from technical modules, which can be used in production or the work area. Each module instance 22a, 22b, 22c, 22d, 22e is equipped with an RTLS transponder T, which the tracking infrastructure uses to determine its position in space.

[0043] To reduce user interactions using RTLS, the definition of so-called virtual geofences is provided. Module instances 22a, 22b, 22c, 22d, 22e are positioned within a virtual area of ​​a production hall or the workspace of a laboratory environment, monitored by the RTLS system. Such a geofence G is assigned to an orchestration configuration for instance transformation. As soon as the transponder of a module instance 22a, 22b, 22c, 22d, 22e is detected within one of these geofences, the instance is added to the corresponding orchestration configuration.

[0044] If only one suitable module instance is available for a module role in the corresponding Geo-Fence G, the instance assignment can be performed directly. In all other cases, only the suitable module instances 22a, 22b, 22c, 22d, and 22e, which are located in the Geo-Fence G of the corresponding orchestration rule, are offered for selection.

[0045] FIG 4 illustrates the determination of available module instances 22 based on an SNMP protocol. When provisioning module instances 22, several settings related to communication and identification are typically configured, such as the IP address. To simplify future work with these technical modules, network settings are configured so that they can be used for all future plant configurations. The approach of this mechanism is that each production area or work area in which module instances 22f, 22g, 22h, 22i, 22j are to be used and identified is equipped with an active network component 27, 28, e.g., a so-called "managed switch". Through the integration of the module instance 22f, 22g, 22h, 22i, 22j via communication technology and monitoring by an SNMP monitor 29, it is recognized which instance 22f, 22g, 22h, 22i, 22j is located at which position in the network.From this, a possible module instance assignment can be derived, similar to the case of RTLS, and used in the course of instance transformation 8.

[0046] Although the invention has been illustrated and described in detail by the preferred embodiment, the invention is not limited by the disclosed examples and other variations can be derived by the person skilled in the art without leaving the scope of protection of the invention.

Claims

Patent claims 1. A method for the automated generation of automation for a technical plant, in particular a manufacturing or process plant, which technical plant comprises a plurality of individual technical modules, by means of a computer-implemented orchestration service, the method comprising: a) subdividing a basic flow diagram, which includes a description of a manufacturing and / or process engineering process to be implemented in the technical plant, according to the individual technical modules, b) extending the subdivided basic flow diagram with semantically unambiguous capabilities that the technical modules must each possess to implement the manufacturing and / or process engineering process in order to generate an abstract orchestration instruction (5), c) including MTP files formed in accordance with the standard VDI / VDE / NAMUR 2658, which is valid at the time of the present patent application,which include a semantically unambiguous description of the types of technical modules available in the technical system, comparison of the semantically unambiguous capabilities from the abstract orchestration rule (5) with the descriptions of the available types from the MTP files, d) If a match is found during the comparison, assignment of the respective type of technical module to the respective semantically unambiguous capability in order to generate a type-specific orchestration rule (7), e) Automated determination of the technical modules available in the technical system and assignment of each of these technical modules to a type of technical module contained in the type-specific orchestration rule (7) in order to generate the automation as an instance-specific orchestration rule (9).

2. Method according to claim 1, wherein the automated determination of the technical modules available in the technical system is carried out using a real-time localization system.

3. Method according to claim 2, wherein the real-time localization system determines the positions of the technical modules within the technical system by means of a wired or wireless transmission of communication telegrams to the technical modules of the technical system and a comparison of the runtimes of the transmitted communication telegrams were determined.

4. Method according to one of the preceding claims, wherein the automated determination of the technical modules available in the technical system is carried out using network identification within a communication network of the technical system.

5. The method of claim 4, wherein the Simple Network Management Protocol (SNMP) is used for network identification.

6. Method for generating an abstract orchestration rule by a computer-implemented orchestration service, comprising: a) Starting from an instance-specific orchestration rule (9) used for the automation of a technical plant, in particular a manufacturing or process plant, wherein the technical plant comprises a plurality of individual technical modules, abstracting the instance-specific orchestration rule (9) to a type-specific orchestration rule (7) incorporating the technical modules available in the technical plant; b) Abstracting the type-based orchestration rule (7) to an abstract orchestration rule (5) incorporating MTP files formed in accordance with the VDI / VDE / NAMUR 2658 standard, which is valid at the time of the present patent application.which include a semantically unambiguous description of the types of technical modules available in the technical plant.

7. The method of claim 6, wherein, following the method steps a and b according to claim 6, the method steps c, d and e according to claim 1 are carried out.

8. The method of claim 7, wherein a method according to one of claims 2 to 5 is additionally carried out.

9. Method for operating a technical plant, in particular a manufacturing or process plant, which technical plant comprises a plurality of individual technical modules, including automation that has been generated according to one of the preceding claims.

10. A computer-implemented orchestration service configured to perform a method according to any one of claims 1 to 8.

11. A technical system comprising a computer-implemented orchestration service according to claim 10.

12. Control system for a technical plant comprising an operator station client and an operator station server for operating and monitoring the technical plant, wherein the orchestration service according to claim 10 is computer-implemented on the operator station server.

Images