MODULE FOR A TECHNICAL PLANT AND METHOD FOR CONTROLLING A TECHNICAL PLANT

Description

1. Field of the invention

[0001] The present invention relates to technical systems and their control. In particular, the present invention relates to modularly constructed process and production systems. 2. State of the art

[0002] In the process industry, particularly in the chemical, pharmaceutical, and food manufacturing sectors, product demand is becoming increasingly difficult to predict and fluctuates regionally over short periods. Furthermore, the global availability of alternatives is leading to ever shorter product lifecycles.

[0003] Conventional production facilities are often not designed for these fluctuating product quantities. Continuously operated systems are usually optimized for a specific product quantity per unit of time and can only operate effectively at this production rate. Standard batch production systems are less efficient and require significant unproductive time, such as cleaning or changeover times.

[0004] When expanding or upgrading a system, it is usually necessary to reconfigure or reprogram the corresponding system control. This is a complex process that often takes about the same amount of time as a hardware upgrade. This is further complicated by potentially inadequate documentation of the existing control software or outdated control hardware that may not provide sufficient functionality for the new hardware.

[0005] Recent developments in the process industry focus on modular plant concepts, where the plant is built from individual prefabricated modules. Such concepts and their challenges are explored in a survey. " Modular plant design and automation using the F3 project" by Dipl.-Ing. Sabine Mühlenkamp / Wolfgang Ernhofer, May 10, 2012, in "Process " described. Here too, the control-related integration of the modules is considered an open question.

[0006] Corresponding modular concepts can also be transferred to other production processes, e.g. for the production of consumer goods, industrial products, etc.

[0007] In such modular concepts, each plant module provides its process engineering or production engineering function as a service to a higher-level process control level (PCL). It thus assumes the position of a service provider. The service offered by the plant module can be accessed by the process control level, which is therefore a service user. The integration of several plant modules and their services into a complete plant is referred to as PCL engineering.

[0008] The document "DIMA - Decentralized Intelligence for Modular Systems" by WAGO Kontakttechnik GmbH & Co. KG describes a modular and decentralized automation of a process engineering production plant with modules according to the preamble of claim 1.

[0009] The objective of the present invention is therefore to improve the modules of a technical system with regard to their control engineering integration and thus to facilitate PFE engineering overall. 3. Summary of the invention

[0010] The above problem is solved by a module for a technical system according to claim 1, a technical system according to claim 14, and by a method for controlling a technical system according to claim 15.

[0011] In particular, the above problem is solved by a module for a technical system comprising technical hardware for carrying out a technical subprocess, a controller for local control of the technical hardware, wherein the controller is configured to control the technical hardware autonomously, and the module has an external interface of the controller, wherein the external interface is configured to receive commands corresponding to the defined states of the module, and wherein the external interface of the controller includes a server, and the server has a fixed, predefined information structure with static information and dynamic information, wherein the static information describes the technical hardware and the controller, and the controller writes the dynamic information as real-time values ​​of the technical hardware into the information structure, wherein the controller is configuredto autonomously bring the technical hardware into a state from a number of defined technical states based on the defined states, and to autonomously switch between the states.

[0012] A technical system can be built from several of these modules. If more production capacity is required, modules can be easily added to the system and then perform specific subprocesses. Because the control system of each module manages the technical hardware locally and autonomously, and can, for example, bring it into specific defined states without external control, the control effort of the overall system is minimized. The module's control system can therefore be provided, programmed, and configured by the module manufacturer, allowing the system manufacturer to create the control system for the entire system with very little effort. Each module can offer one or more technical services that can be integrated into the overall system during PFE engineering and then used.

[0013] Since the controller's external interface includes a server, communication with the module can be simple and standardized. In particular, this allows for targeted queries of specific information from the module, while irrelevant information is not transmitted. Specifically, the server has a predefined information structure containing static and dynamic information about the module's technical hardware. Therefore, targeted queries for relevant information can be directed to the module. The static information describes the technical hardware and the controller, thus providing all the information required for PFE engineering.This information may include, for example, a detailed description of the services offered by the module, a description of the available states and the control engineering behavior of the module, a description of the available commands and their syntax, and a description of the readable state information and measured values.

[0014] In addition, the available information structure also includes dynamic information as real-time values ​​from the technical hardware and therefore offers the possibility of communication with the module during operation. These real-time values ​​from the technical hardware are written to the information structure on the server by the controller. This allows even dynamically changing real-time values ​​to be easily and specifically retrieved externally, for example, by a controller at the higher-level process control level.

[0015] Through the static and dynamic information made available on the server, the module provides a complete module type package that forms part of the administration shell in Industry 4.0 and encompasses all data and information for the virtual and functional representation of the module. The controller provides all data and information for both PFE engineering and ongoing operation on the server.

[0016] During PFE engineering, the modules are integrated into the PFE by reading the modules' MTPs into the PFE and generating the necessary components on the PFE side for each required module. This includes both the interface to the module's information model and the module's graphical representation. Additionally, the cross-module procedure is configured in the PFE. Furthermore, a procedure control is created for the timely retrieval and monitoring (orchestration) of the module services. The control of the module services is parameterized, and, if necessary, cross-module interlock logic is generated.

[0017] Finally, the physical communication is mapped and parameterized in network engineering.

[0018] Preferably, the controller generates real-time values ​​from control data and / or measurement data from the technical hardware. This makes control data and / or measurement data, such as measured values, control parameters, or setpoints, etc., from the technical hardware available for retrieval or communication.

[0019] Preferably, the controller generates real-time values ​​from the states of the service provided by the technical hardware. This allows the states of the technical hardware, such as "in operation", "stopped", "under maintenance", "defective", "heating up", or the order schedule, occupancy times, maintenance schedule, etc., of the technical hardware, to be made available for retrieval or communication.

[0020] Preferably, the controller generates real-time values ​​from historical values ​​of control data and / or measurement data from the technical hardware and / or communication data. This allows real-time values ​​to be made available for retrieval or communication that take the past or history into account or are calculated from historical values. For example, the next maintenance date for the technical hardware could be dynamically calculated and provided by the controller based on current load and past runtimes at different load levels or the number of critical states of the technical hardware. Control data can also include the states of services provided by the technical hardware.

[0021] Preferably, historical values ​​can be data such as threshold exceedances, peak values, and temperature profiles. Historical values ​​can also preferably be timestamped.

[0022] Preferably, the controller generates real-time values ​​by extrapolating control data and / or measurement data from the technical hardware and / or communication data. The controller can also calculate and provide real-time values ​​extrapolated into the future. For example, the controller can calculate and provide temperature profiles, necessary maintenance or downtime under current load, necessary future cooling phases, available time slots, potential limitations on maximum rotational speed, etc. The controller can use different models for extrapolation.

[0023] Preferably, the server's information structure comprises a number of objects, each containing at least one real-time value and a description of that value. The real-time values ​​are stored in server objects, allowing for easy retrieval, identification, or referencing.

[0024] Preferably, the object description is a standardized meta-information for the real-time value. This allows an external device to query the presence of the real-time value via the external interface.

[0025] Preferably, the object's real-time value includes a timestamp. This allows multiple real-time values ​​to be synchronized and the evolution of real-time values ​​over time to be easily analyzed or visualized.

[0026] Preferably, the control of the technical hardware is carried out via at least one service provided by the controller and by the controlled technical hardware, wherein the at least one service is represented in the information structure in the server.

[0027] Preferably, the objects of the server's information structure form a Module Type Package (MTP) that contains all the information necessary for integrating the module into a technical system. The module's controller thus provides all the necessary information in its external interface, which includes the server, so that the module can be identified, integrated into the overall system, and parameterized during the PFE engineering phase. Furthermore, the MTP also provides the dynamic information that is necessary or advantageous for communication with other controllers.

[0028] Preferably, the control system is designed so that the server can be queried dynamically, especially for each object individually. This allows only the information that is currently relevant to be retrieved from the outside. Irrelevant information therefore does not need to be transmitted, minimizing data transfer on the network or bus.

[0029] The controller prefers to continuously update the server's real-time values. This ensures that the information in the Type Package module is always up to date.

[0030] Preferably, the external interface remains configured to output information to or receive information from upstream, downstream, or parallel modules. The module can communicate directly with other modules and exchange information, such as commands, with them. For example, a module could request an input product from a module upstream in the process.

[0031] Preferably, the external interface remains configured to receive information from or send information to a higher-level plant control system. The module can also communicate with higher-level plant control systems, for example, receiving commands or instructions and sending messages back to them. However, it is also preferable to forgo a higher-level plant control system. In this case, the modules communicate with each other as described above.

[0032] Preferably, the technical hardware is configured to produce an output product from an input product, and the technical hardware is further configured to modify the input product to produce the output product by changing its chemical composition, and / or changing at least one physical property, and / or adding material, and / or removing material. The technical hardware preferably has an input product and an output product, and it modifies the input product such that an output product is produced. A product is defined as being able to be modified by the technical hardware using at least one of the four methods mentioned. Value is added by the modification of the input product into an output product by the technical hardware. Therefore, the overall process includes at least one piece of technical hardware of this type that generates added value.Preferably, the technical hardware includes an actuator that acts on the input product.

[0033] Preferably, the server should be an OPC-UA server.

[0034] Preferably, a technical system has several of the modules described above.

[0035] The above-mentioned task is also solved by a method for controlling a technical system, wherein the system is composed of several modules, each comprising technical hardware for carrying out a technical subprocess, as well as a controller for local control of the technical hardware and an external interface of the controller, wherein the external interface includes a server which has a fixed information structure with static information and dynamic information, wherein the static information describes the technical hardware and the controller, and the method comprises the following steps: a. Writing the dynamic information into the information structure as real-time values ​​of the technical hardware by the controller; and b. Providing the dynamic information in the server's information structure.

[0036] This also achieves the advantages described above for the module; in particular, it creates a way to easily and purposefully retrieve dynamically changing real-time values ​​from the outside during operation, for example by controlling a higher-level process control system or by other modules.

[0037] Through the static and dynamic information made available on the server, the process provides a complete module type package, which forms part of the administration shell in Industry 4.0 and encompasses all data and information for the virtual and functional representation of a module. The controller provides all data and information for both PFE engineering and ongoing operation on the server.

[0038] Preferably, the process further comprises at least one or more of the following steps: c. Generating real-time values ​​from control data and / or measurement data of the technical hardware by the controller; d. Generating real-time values ​​from states of the service provided by the technical hardware by the controller; e. Generating real-time values ​​from historical values ​​of control data and / or measurement data of the technical hardware and / or communication data; f. Generating real-time values ​​by extrapolation based on control data and / or measurement data of the technical hardware and / or communication data.

[0039] This allows the controller to calculate and provide real-time values ​​based on control data, measurement data, states, the service provided by the technical hardware, historical values ​​thereof, and / or extrapolation. Accordingly, the controller can provide real-time module values ​​based on the module's present, past, and future state. In particular, the controller can thus provide, within a Module Type Package (MTP), the dynamic information necessary or advantageous for communication with other controllers.

[0040] Further preferred embodiments of the invention are set forth in the dependent claims. 4. Brief description of the drawings

[0041] Preferred embodiments of the present invention are described below with reference to the drawings, which show: Fig. 1 a schematic view of a technical plant with several modules and a higher-level plant control system; Fig. 2 a diagram showing the communication between a module of a technical plant and a process control level; Fig. 3 a diagram illustrating an exemplary architecture of a Module Type Package Manifest; Fig. 4 a diagram illustrating an exemplary architecture of an operator interface description; and Fig. 5 a diagram illustrating an exemplary architecture of an object "Service". 5. Description of preferred embodiments

[0042] Preferred embodiments of the present invention are described in detail below with reference to the figures.

[0043] Figure 1Figure 90 shows a technical system 90, which is composed of several individual modules 1, 70, 80 and possibly other modules not shown. The technical system 90 also includes a process control level (PCL) 60, which is formed, for example, by a higher-level controller 60 that communicates with the individual modules 1, 70, 80 via a suitable bus 62.

[0044] Module 1 of technical system 90 is representative of all modules 1, 70, and 80 of technical system 90. It comprises technical hardware 10 for carrying out a technical sub-process, for example, in the chemical industry. However, the technical system can also relate to other technical manufacturing processes, such as the production and assembly of products, packaging technology, logistics, etc.

[0045] Preferably, the technical hardware 10 of module 1 is configured to produce an output product 140 from an input product 130. For this purpose, the technical hardware 10 is further configured to modify the input product 130 to produce the output product 140. This can be achieved by changing its chemical composition, as is common practice in reactors in the chemical industry. It can also be achieved by changing at least one physical property, such as temperature, density, entropy, etc. Furthermore, the production of an output product 140 can be achieved by adding material, for example, during assembly, soldering, printing, or 3D printing. Finally, production can also be achieved by removing material, as is the case, for example, during drilling, milling, etching, etc.

[0046] Value is added by the transformation of input product 130 into output product 140 by the technical hardware 10. Therefore, the overall process includes at least one piece of technical hardware 10 of this type that generates added value. Preferably, the technical hardware includes at least one actuator in the broadest sense that acts on the input product 130, for example, a vaporizer.

[0047] In the illustrated process engineering example, the technical hardware 10 comprises an actuator in the form of a reactor 30, which includes a mixer 40 driven by an electric motor 42. The reactor 30 also includes an electric heating element 50, which is controlled by power electronics 52. The reactor 30 itself consists of a preferably closed vessel to which an inlet pipe 32 and an outlet pipe 34 are connected for filling and emptying. The inlet pipe 32 extends to the outer boundary of the exemplary module 1 and terminates there in an inlet flange 36. An input product 130 can be fed into the reactor 30 through the inlet flange 36 and the inlet pipe 32. Likewise, the outlet pipe 34 extends to the system boundary of module 1 and terminates there in an outlet flange 38. A feedstock from reactor 30 can be discharged through the outlet flange 38 and the outlet pipe 34.Module 1 can be connected to an upstream module 70 via the inlet flange 36 and to a downstream module 80 via the outlet flange 38. Of course, other technical connection options are also possible, such as multiple inlets or outlets, or parallel connections of modules 1, 70, and 80.

[0048] Module 1 also includes a controller 20 for the local control of its technical hardware 10. The controller 20 is configured to autonomously control the technical hardware 10, for example, the electric motor 42 of the agitator 40 and the power electronics 52 of the heating element 50. Thus, the controller 20 is able, for instance, to bring Module 1 into a defined technical state. Module 1 can have a number of precisely defined technical states and can autonomously switch between these states on command. This allows the module, for example, to autonomously carry out a technical subprocess without external influence.

[0049] Module 1 can also include, for example, sensors such as flow, pressure, or temperature sensors, or electrically operated valves or similar elements (not shown). Such sensors or actuators are also connected to the controller 20 and can be queried or controlled by the controller 20.

[0050] The controller 20 has I / O modules 24 and 26 for this purpose, which it can use to control actuators such as the electric motor 42 of the agitator 40 or the power electronics 52 of the heating element 50. Additional I / O modules for sensors or other actuators are available if required for the technical function of module 1.

[0051] Modules 70 and 80, and other modules, can be structured similarly to module 1, also featuring a control system similar to control system 20. This control system can locally and autonomously manage the technical hardware of the respective module and bring the module into a number of specific, defined states. Accordingly, modules 1, 70, and 80 are inherently self-contained in terms of their control system, so that the technical hardware and control system together form a flexibly deployable module for a technical system 90, which can be controlled virtually by "plug and play" can be technically and control-technically assembled into a complete system 90.

[0052] The overall system 90 comprises a process control level 60, including a higher-level controller 60, which is connected to the individual modules 1, 70, and 80 via a bus 62. The higher-level controller only needs to send precisely defined commands to the individual modules 1, 70, and 80 so that they assume one of their predetermined, defined states. The higher-level controller 60 does not need to know the control details or the individual elements of the technical hardware 10 of the respective modules 1, 70, and 80, nor does it need to control these individual elements. On the contrary, the higher-level controller 60 should preferably only send "high-level" commands to the individual modules 1, 70, and 80, so that they can then autonomously assume the respective states to carry out their respective technical subprocess. This control concept simplifies the planning, design, and construction of technical systems 90.Module 1 essentially brings with it its complete control system in a modular manner, in addition to its technical hardware 1, thus minimizing the overall control effort.

[0053] For communication between the controller 20 of module 1 and the higher-level controller 60 or the other modules 70, 80 via bus 62, the controller 20 has an external interface 22. The external interface 22 includes a server 28 for communication with the process control level 60 and the other modules 70, 80 of the plant 90. The server 28 is preferably an OPC UA server 28. The OPC UA server 28 has a predefined information structure that includes static and dynamic information. The static information describes the technical hardware 10 and the controller 20, so that during PFE engineering, module 1 can be identified as a suitable service provider and integrated accordingly into the overall plant 90, both technically and in practice.The static information can include, for example, descriptions of the services offered by Module 1, specifications of the input products, specifications of the output products, information on production resources such as electricity, water, etc., user documentation, interface definitions with a corresponding description of the command syntax, information on direct recording of communication from the process control level to Module 1, a graphical representation of Module 1, etc.

[0054] In addition to static information, the information structure of the OPC UA server 28 also includes dynamic information concerning module 1, which can change over time. This allows module 1 to communicate with other plant components, particularly the process control level 60, via the OPC UA server 28, even during operation, and to provide or exchange dynamic information. The dynamic information is written into the information structure of the OPC UA server by the controller 20 as real-time values ​​from the technical hardware 10.

[0055] Through the static and dynamic information made available in the OPC UA Server 28, Module 1 can provide a complete Module Type Package (MTP) 100, which forms part of the administration shell in Industry 4.0 and includes all data and information for the virtual and functional representation of a module. This provision of an MTP 100 by Module 1 as a service provider to the Process Control Level (PFE) 60 as a service user is exemplified in Fig. 2 illustrated.

[0056] The MTP 100 can also include the information used for orchestration, i.e., retrieving and monitoring the services of Module 1. Fig. 3 The diagram shows an example architecture of a Module Type Package 100 manifest. This manifest contains the data and information for the virtual and business representation of Module 1. The MTP 100 is mapped in the information model of the OPC UA server 28.

[0057] In addition to the version ("MTP / version"), manufacturer information, and a unique MTP ID ("MTP / uid"), the manifest can also contain links to the description files for the following aspects: For example, the manifest includes a link to the state model of the module or all services ("Module statemodel"): Each module implements at least one service. It therefore executes at least one function. The PFE 60 should be informed about the current state of the function to prevent unwanted overlaps in the process flow, such as simultaneous heating and cooling of the same container.

[0058] The manifest also includes, for example, a link to the description of Module 1's external interface 22 ("Communications"): Module 1 is addressed by the PFE 60 via its own external interface 22. For the OPC UA Server 28 integrated into external interface 22, the URL and IP address are required ("OPCUA Server"). This information must be present in the manifest, whereby integration-dependent parameters, such as the IP address, can be added later during PFE engineering or may change dynamically.

[0059] The manifest, for example, also includes a link to all services that the module provides to the PFE ("Services"). Typically, Module 1 can implement multiple functions, such as stirring and tempering, as separate services. These can be integrated into the higher-level process control via PFE 60. An example of the structure of a service is shown in the "services.aml" object 120, which is located in Fig. 5 The technical hardware 10 can be controlled via one or more such services. The service(s) are provided by the controller 20 and the technical hardware 10 and are represented in the information structure in the OPC UA server 28.

[0060] The manifest also includes, for example, a link to the description of the user interface ("HMI"). The operator panel hierarchy within the module and references to the operator panel descriptions must be reported to PFE 60. Therefore, links to the corresponding descriptions are provided from the manifest.

[0061] PLT Location Information ("PCE Request") If the internal PLT locations of the module are to be disclosed to the PFE, a link to the corresponding description file must be included in the manifest. The characteristics of the Services and User Interface aspects each refer to one or more files in the MTP folder structure. Each service has its own independent state model. A "Dependency" section in the MTP is provided for describing dependencies between different services (e.g., simultaneous exclusion, sequences, etc.), in which a behavioral description is formally represented.

[0062] The user interface aspect is divided into the operator panel hierarchy and the operator panel description. The operator panel hierarchy ("Picture") is part of the MTP manifest. The individual operator panel descriptions themselves ("hmi.graphml") are stored in easily interchangeable files within the MTP folder structure. The well-supported GraphML format, with its numerous tools and libraries, can be used as the modeling language for the operator panels, which consist of nodes (objects) – representing process equipment such as valves, pumps, etc. – and edges – for mapping piping and information flows.

[0063] The architecture of an operator interface description is in Fig. 4The interface is represented as a graph. Nodes correspond to the control panel elements and, in addition to their function, also contain location, size, and variable information. Nodes can be connected by edges. An edge can thus be interpreted as a pipeline or information flow on the control panel. To make the module's diagnostic information accessible to the operator, each control panel also includes corresponding status indicators with links to the relevant variables. Ultimately, the control panel is displayed as a graph and is therefore relatively easy to interpret during PFE engineering.

[0064] The controller 20 can generate real-time values ​​from control data and / or measurement data from the technical hardware 10, which are written into the information structure of the OPC UA server 28. This makes parameters, such as measured values, control parameters, or setpoints, etc., of the technical hardware 10 available for retrieval or communication. In the example of module 1, the real-time values ​​could be, for example, the speed of motor 42 or the current temperature of reactor 30.

[0065] In addition, the controller 20 can generate real-time values ​​from the states of the service provided by the technical hardware 10. This allows the states of the technical hardware 10, such as "in operation," "stopped," "under maintenance," "defective," "heating up," or the job schedule, occupancy times, maintenance plan, etc., of the technical hardware 10 to be made available for retrieval or communication. In the example of module 1, the real-time values ​​could be, for example, the states "mixing" and "heating up," or the availability or unavailability of a specific service. For example, if the heating element 50 needs to be replaced, but the mixer 40 is available during this time.

[0066] Furthermore, the controller 20 can also derive real-time values ​​from historical values ​​of control data and / or measurement data from the technical hardware 10 and / or

[0067] Generate communication data. This allows real-time values ​​to be provided for retrieval or communication, taking into account past or historical data or calculated from historical values. For example, the next maintenance date for the technical hardware 10 could be dynamically calculated and provided by the controller 60 based on current load and past runtimes at different load levels or the number of critical states of the technical hardware 10. If, for example, the mixer 40 can be operated by the motor 42 at different speeds and power levels, the availability of module 1 may depend on the speeds and power levels of past jobs. If necessary, the motor 42 must be operated at a lower power or speed for cooling during the current job.

[0068] Furthermore, the controller 20 can generate real-time values ​​by extrapolating parameters of the technical hardware 10 or states of the service provided by the technical hardware 10. The controller can also calculate and provide real-time values ​​extrapolated into the future. For example, the controller can calculate and provide temperature profiles, necessary maintenance or downtimes under current load, necessary future cooling phases, available time slots, possible limitations on maximum rotational speed, etc. The controller 20 can use different models for extrapolation. This allows the controller 20, for example, to offer a service only under certain boundary conditions after completion of a task at the process control level 60. For example, if the motor 42 is still heated, stirring a product in the reactor 30 may only be permitted up to a certain power level.up to a certain engine speed 42 or only for a limited period of time.

[0069] Each module type is developed uniquely. This includes both the physical design of the process step to be implemented within it and the creation of the IT interface to higher-level systems. In addition, the engineering for the control logic and user interfaces is required. Ultimately, the engineering is carried out as with a small plant, with the difference that Module 1 must be designed generically for various applications. In addition to the physical and IT design of the module, the MTP 100 for integration into the PFE 60 must be generated and delivered together with Module 1.

[0070] During PFE engineering, Module 1 is integrated into PFE 60 by reading the MTPs 100 of Module 1 into PFE 60 and generating the necessary components on the PFE side for each required Module 1. This includes the interface to the information model of Module 1 as well as the graphical representation of Module 1. Additionally, the cross-module procedure in PFE 60 is configured. The procedure control for the timely retrieval and monitoring (orchestration) of the module services is created. The control of the Module 1 services is parameterized, and, if necessary, cross-module interlock logic is generated. Finally, the physical communication is mapped and parameterized in network engineering.

[0071] Furthermore, the controller 20 can independently handle all safety, signaling, and logging functions for the respective module 1, thus relieving the higher-level controller 60 or process control level 60 of this task. It is also possible to operate module 1 manually via the controller 20 without a higher-level controller, for example, when only very small quantities are to be produced and integration into a higher-level controller would not be worthwhile. For this purpose, module 1 has its own user interface or control panel.

[0072] Via the OPC UA Server 28, Module 1 can also output or provide information, such as defined commands, to upstream, downstream, or parallel modules. For example, Module 1 can inform upstream Module 70 to forward a semi-finished product to Module 1 if Module 1 is to process it. Similarly, Module 1 can issue a defined command to downstream Module 80 when it has completed processing and wants to forward the finished semi-finished product to Module 130 for further processing. Accordingly, Modules 1, 70, and 80 can implement horizontal communication with each other without necessarily requiring a higher-level controller or PFE 60 as an intermediary.

[0073] Examples of defined states for modules 1, 70, and 80 are: "idle," "running," "halt," "stopped," "aborted," and "finished." Furthermore, the "running" state can be subdivided into different operating modes if this is possible for the subprocess. This allows the subprocess to run, for example, with different parameters or with different sequences. Accordingly, appropriately defined commands can be transmitted to module 1 via the external interface 22 to instruct its controller 20 to move to the corresponding state. The transition between the individual states can then be autonomously controlled by the controller 20.

[0074] For communication with the OPC UA servers 28 of modules 1, 70, and 80, the process control level 60 includes an OPC UA client 64. This client can send corresponding queries to the OPC UA server 28 and retrieve or store information there in a targeted manner. The process control level 60 also includes a module 66 for the actual process control and a module for a human-machine interface (HMI) 68. In addition, the process control level 60 can execute further functions using other elements or modules 69. Reference symbol list:

[0075] 1 Module 10 Technical Hardware 20 Control 22 External Interface 24, 26 I / O Module 28 Server, OPC UA Server 30 Reactor 32 Inlet Line 34 Outlet Line 36 Inlet Flange 38 Outlet Flange 40 Agitator 42 Motor 50 Heating Element 52 Power Electronics 60 Process Control Level (PFE) / Higher-Level Control 62 Data Bus 64 OPC UA Client 66 Process Control 68 Operator Interface 69 Other Elements 70, 80 Other Modules 90 Technical System 100 Module Type Package / MTP Manifest 110 User Interface Description 120 Object "service.aml" 130 Input Product 140 Output Product

Claims

1. Module (1) for a technical facility (90), comprising: a. technical hardware (10) for performing a technical subprocess; b. a controller (20) for locally controlling the technical hardware (10), wherein the controller (20) is configured to autonomously control the technical hardware (10); and c. an external interface (22) of the controller (20), wherein the external interface (22) comprises a server (28); d. the server (28) comprises a fixedly predefined information structure with static information; e. wherein the static information describes the technical hardware (10) and the controller (20); and f. wherein the controller (20) is configured to bring the technical hardware (10) based on the defined states autonomously into one state of a number of defined technically states and to autonomously change between the states; characterized in that g. the fixedly predefined information structure of the server (28) further comprises dynamic information and the controller (20) writes the dynamic information into the information structure as real-time values of the technical hardware (10); and h. the external interface is configured to transmit correspondingly defined instructions to the module (1) via the external interface (22) to instruct the controller (20) to approach the corresponding state.

2. Module according to claim 1, wherein the controller (20) is configured to generate the real-time values from control data and / or measurement data of the technical hardware (10).

3. Module according to one of the claims 1 or 2, wherein the controller (20) generates the real-time values from states of the service provided by the technical hardware (10).

4. Module according to one of the claims 1 to 3, wherein the controller (20) generates the real-time values from historical values of control data and / or measurement data of the technical hardware (10) and / or communication data.

5. Module according to one of the claims 1 to 4, wherein the controller (20) generates the real-time values by extrapolation based on control data and / or measurement data of the technical hardware (10) and / or communication data.

6. Module according to claim 1 to 5, wherein the information structure of the server (28) comprises a number of objects each comprising at least a real-time value and a description of the real-time value.

7. Module according to claim 6, wherein the description in the object is a standardized meta-information for the real-time value.

8. Module according to one of the claims 6 or 7, wherein the real-time value of the object comprises a time stamp.

9. Module according to one of the claims 1 to 8, wherein the control of the technical hardware is effected via at least one service which is provided by the controller and by the controlled technical hardware, wherein the at least one service is mapped in the information structure in the server.

10. Module according to one of the claims 6 to 9, wherein the objects of the information structure of the server (28) form a module type package (100) which contains all information which is necessary for integrating the module into a technical facility (90).

11. Module according to one of the claims 1 to 10, wherein the controller (20) is configured such that the server (28) can be queried dynamically, in particular individually for each object.

12. Module according to one of the claims 1 to 11, wherein the external interface (22) is furthermore configured to output information to or receive information from modules (70, 80) connected upstream or downstream or in parallel.

13. Module according to one of the claims 1 to 12, wherein the server (28) is an OPC-UA server.

14. Technical facility (90) comprising a plurality of the modules (1, 70, 80) according to one of the claims 1 to 13.

15. Method for controlling a technical facility (90), wherein the facility (90) is constructed from a plurality of modules (1, 70, 80) which each have a technical hardware (10) for carrying out a technical subprocess, and have a controller (20) for locally controlling the technical hardware (10) and an external interface (22) of the controller (20), wherein the external interface (22) comprises a server (28) which has a fixedly predefined information structure with static information, wherein the static information describes the technical hardware (10) and the controller (60), and wherein the controller (20) is configured to autonomously control the technical hardware (10) based on the defined states and autonomously control the transition between the states, characterized in that the fixedly predefined information structure of the server (28) further comprises dynamic information; and the method comprises the following steps: a. writing the dynamic information into the information structure as real-time values of the technical hardware (10) by the controller (20); b. providing the dynamic information in the information structure of the server (28); and c. transmitting correspondingly defined instructions to a module (1) via the external interface (22) to instruct the controller (20) of the module to approach the corresponding state.