Method and apparatus for connecting function controllers in a distributed automation system - Patents.com

Abstract

Method and device for connecting functional controls in distributed automation systems. In today's automation systems, there is a tight coupling between the functional implementation and its connection to the physical process. This coupling is characterized in particular by the fact that the integration options of distributed peripherals are limited to the integration of individual hardware specific signals. A component-based and function encapsulated system architecture is proposed, which solves the current challenges by associating increasingly intelligent devices in the field as functional components.

Description

[Technical field]

[0001] The present invention relates to a method and apparatus for connecting function controllers in a distributed automation system. [Background technology]

[0002] The trends towards increased product individualization, shorter product life cycles and increased market volatility were first observed in production automation and are now also being observed in the process industries. These market developments require greater variability of production plants. This variability depends on five enabling features: universality, mobility, scalability, modularity and interchangeability. - Universality refers to the sizing and configuration of the plant to suit different product and technology requirements (e.g., variety of variants). - Mobility provides locally unrestricted movement of an object (e.g., equipment on rollers). - Scalability means technical, spatial and human resource ventilation (= expandability and contractibility) is desirable (e.g. economically adjusting the size of the plant according to the prevailing market demand). - With regard to modularity, units or elements of standardized functionality will be created (eg "plug and produce" modules). -Finally, compatibility ensures the interoperability of materials, information, media and energy (e.g. uniform software interfaces).

[0003] These features are useful not only in the hardware configuration of a production plant, but also in the configuration of automation engineering, which is a challenge in modern automation systems.

[0004] In modern automation systems, there is a tight coupling between the functional implementation and its connection to the physical process. This coupling is characterized in particular by the fact that the options for integrating distributed peripherals are limited to the integration of individual hardware-specific signals. Here, different sensors and actuators are controlled via different interfaces, even if they perform similar or identical tasks. This hampers many change enablers.

[0005] Regarding universality, there is a problem that the diversity of variations in the implementation of sensor logic and actuator logic is almost impossible to realize because the diversity of variations is reflected in different signal interfaces. For the same reason, the use of more intelligent field devices or more powerful technologies is also limited, thus hindering the change enabler of scalability.

[0006] Regarding the information flow between distributed peripherals and automation systems, compatibility is only possible if the corresponding signal interfaces match. Compatibility cannot be guaranteed in the presence of different sensor and / or actuator types and the associated signal interfaces.

[0007] The connection of distributed peripherals with automation systems based on individual signals involves a lot of individual wiring and the use of additional remote I / O assemblies, which limits the mobility of sensors and actuators, since it restricts them from simply reconnecting them to another location in the plant.

[0008] Plant modularity is crucial in implementing the above change enablers. Currently, modularity is often limited to the physical structure of the plant and is not reflected in the automation software.

[0009] In summary, it can be concluded that the connection of distributed peripherals with automation systems is traditionally based on individual signals that directly control sensors and actuators. This was sufficient in the past because the automation software was based on converting input signals into output signals using simple signal conversion logic. However, as soon as the plant has variability requirements, this concept presents the above challenges.

[0010] Prior Art An existing approach to solving the above problems is the use of intelligent field devices, i.e. the use of distributed intelligence. The logic for controlling individual small sensors and actuators is implemented not in the automation system but directly in the field, i.e. where this logic is needed. Such an approach is known, for example from edge environments. This has the advantage that the automation system does not need to process individual signals for controlling distributed peripherals. Instead, the functionality of sensors, actuators or entire control loops is abstracted, defined and made available to the automation system via best standardized interfaces.

[0011] A technology that already uses this idea in current approaches is PROFIBUS PA. In this case, function modules that implement communication in the field without being integrated into the automation system are standardized. In PROFIBUS PA, on the other hand, there is still a signal-based abstraction. In the field of manufacturing, the basis for distributed intelligence is laid in IO-Link technology. Currently, the use of these approaches is limited by the fact that current integration technologies only partially or not at all take into account the integrated functions of intelligent devices.

[0012] An example of such a connection can be found in US Pat. No. 5,399,633, where an Ethernet interface is emulated behind a serial interface, so that the web server can be accessed via the known TCP / IP protocol.

[0013] In addition to these fieldbus systems, some manufacturers also offer microcontrollers that are very good for implementing distributed intelligence in the field, such as the TBEN-L-PLC from Turck, which, in addition to the control components based on CODESYS, also has the option to communicate with other programmable logic controllers (PLCs) or directly with the cloud using various protocols (e.g. PROFINET, Ethernet, Modbus, etc.).

[0014] Finally, according to the VDI / VDE / NAMUR 2658 standard, parts of the overall functions of a process plant are outsourced to modules called Process Equipment Assemblies (PEA) as distributed intelligence. A similar approach is also adopted in the field of research on skills and competencies in the field of production automation. The concept of modular automation based on VDI / VDE / NAMUR 2658 is considered a very good approach to implement distributed intelligence in future automation systems and thus solve the above mentioned challenges.

[0015] Moreover, the architectural concept of VDI / VDE / NAMUR 2658 is explained in detail in Figure 5.

[0016] The hierarchical model is structured from bottom to top as follows. A more detailed description of the individual modules follows: Hardware Settings, HWC Process Image of Inputs, PAE / Process Image of Outputs PAA Signal Abstraction Layer SAL Service Module SM1 Control modules CM1, CM2, CM3 Control module type CMT1,...

[0017] In the example shown, communication is carried out according to the OPC UA standard.

[0018] The current concept of modular automation is based on making process engineering functions available as distributed intelligence, where these functions are implemented in the form of services in modular process units PEA.

[0019] Service module SM and control module CM: A so-called service in this case consists of a service module SM and any number of control modules CM. In the service module, the control logic of the service is implemented based on a standardized state machine. However, it has not yet been decided which sensors and actuators will be used to execute the service. The control modules, on the other hand, encapsulate the logic for controlling the sensors and / or actuators and are thus responsible for connecting the service to the physical process.

[0020] To implement a complete service, the required control modules must be assigned to the service modules. This assignment is implemented flexibly in the architecture concept presented here. For this purpose, the program of the service modules is developed for type interfaces for sensors and actuators. This program contains corresponding placeholder modules where interaction with the production process is required and therefore where control modules need to be integrated. These placeholders are implemented as control module types CMT and have the same standardized interfaces as the control modules that will later fill them. Different control module types CMT are then available with different interfaces for valves, motors, sensors or entire control loops, for example. To implement a service, the interfaces of the desired control modules CM are mapped to the interfaces of the placeholders CMT. In this way, the SMs are assigned the sensors and actuators that are actually to be controlled.

[0021] However, this procedure has the disadvantage that once the allocation has been performed during the engineering of the system, it is no longer possible thereafter to adjust the allocation without adjusting the control program.

[0022] A configuration and runtime interface for the service module SM is provided by an OPC UA server, which is also included in the modular process unit PEA. Via this configuration and runtime interface the configuration and procedure parameters of the service module SM can be set and the state machine of the service module SM can be controlled (started, stopped, etc.).

[0023] Signal Abstraction Layer SAL The interaction between the sensors and actuators of the production process and the control module CM is based on conventional mechanisms. For the hardware configuration HWC, hardware addresses are defined under which the sensors and actuators used can be found. The current values ​​behind these addresses are recorded at the beginning of each PLC control cycle in the input process image PAE for sensor signals and in the output process image PAA for actuator signals. The values ​​stored in PAE and PAA can now be used in the control program of the control module CM. However, to simplify the use of these signals, the hardware addresses themselves are not used in the program, but rather user-defined symbols that are assigned to the hardware addresses. The relationship between the hardware addresses defined in the HWC and the symbols used in the program is realized by means of a mechanism called the signal abstraction layer SAL.

[0024] A modular process unit PEA in the sense of VDI / VDE / NAMUR 2658 therefore provides distributed intelligence that is abstracted via standardized interfaces. In this way, the above-mentioned challenges at PEA level are met. A modular plant in the sense of VDI / VDE / NAMUR 2658 is variable, so that the entire PEA can be integrated, disassembled and replaced.

[0025] In the previous section it was shown that within the modular process unit PEA the interaction with the production process is still based on individual control signals for sensors and actuators.

[0026] The PEA is therefore not configurable with regard to the integration, disassembly and replacement of individual sensors and actuators. This is because the signals necessary for the interaction between the control module CM and the field level can vary depending on the type and variant of the sensors and actuators used. For example, there are valves with no feedback signal, with one feedback signal or with a dual feedback signal. Motors can be implemented with or without a specification of the rotation speed, a rotation speed feedback or a switching of the rotation direction. This diversity of variants cannot be preserved by the signal abstraction layer, since it performs the abstraction at the level of the individual signals. This strongly limits the freedom of exchange of sensors and actuators and therefore the variability of the PEA. [Prior art documents] [Patent documents]

[0027] [Patent Document 1] DE 10 2008 058 033 A1 Summary of the Invention [Problem to be solved by the invention]

[0028] SUMMARY OF THE PRESENT EMBODIMENT It is therefore an object of the present invention to provide a method and system which overcomes the disadvantages presented in the prior art. [Means for solving the problem]

[0029] The invention is defined by a method comprising the features of independent claim 1.

[0030] The system is also indicated by the features of claim 6.

[0031] Further advantageous configurations of the invention are set forth in the dependent claims.

[0032] A component-based functional encapsulation system architecture is presented that solves current challenges by associating increasingly intelligent devices in the field as functional components.

[0033] Basic architectural approach: In contrast to the signal abstraction layer SAL, the transition between the control module CM and the service module SM (hereinafter also referred to as the Component Abstraction and Management Layer CAML) is able to abstract the diversity of the abovementioned variants of sensors and actuators. On this basis, within the scope of the disclosure of the present invention, a system is presented which provides CAML as an abstraction level of sensor and actuator functionality. A possible automation architecture is illustrated in Fig. 3 and is explained in more detail below.

[0034] The basic structure of this architecture is largely based on the VDI / VDE / NAMUR 2658 architecture described in the introduction to this document. However, when distinguishing between both approaches, the concepts of service modules SM, control modules CM and control module templates CMT are no longer chosen, and in the following, service components SC (Service Component), control components CC (Control Component) and control component types CCT (Control Component Type) are mentioned instead. Here, the concept of components is based on the lowest level in the structural model of modular plants according to VDI 2776 (Process engineering plants - Modular plants, Fundamentals and planning modular plants). The control component type CCT makes it possible, for example, to implement a control component element with open, standardized interfaces, in which the assignment of real data of a concrete application is only possible at a later point in time (via the interfaces).

[0035] Control Components Automation devices (sensors, actuators, packaged units, IO stations) are becoming increasingly intelligent and have their own computing power, so their firmware is capable of much more than simply providing signals.

[0036] A CC is a software representation of an automated device. This representation can be implemented in the device itself or in a controller etc. The automated device and the representation are addressable.

[0037] This component is an addressable unit and has a standardized interface (eg according to 2658), which is an essential difference from the control modules CM known from the prior art.

[0038] Device specific peculiarities are resolved locally in the component so that the component always looks the same from the outside. This device can be its own computing resource (embedded device) or can be extended with external computing resources via an existing fieldbus system.

[0039] In summary, the control components have the following technical characteristics: -Connection to industrial processes (production engineering processes or process engineering processes), - Dedicated computing power for processing software (embedded devices, PLCs, edge devices), -Standardized communication technologies (e.g., OPC UA Server / Client, OPC UA Pub / Sub, etc.), -Standardized, function-oriented component interfaces (e.g. according to VDI / VDE / NEMUR 2658), - Device-specific adjustments to accommodate standardized component interfaces are resolved locally with dedicated computing power (e.g., a valve has no feedback, one feedback, or two feedbacks); The control component as a functional unit is addressable as an entity (e.g. opc.tcp: / / 192.168.2.1:4840 / ns=1:s=TI001); has. The control component address depends on the underlying communication technology.

[0040] Service Components The services encapsulate automation engineering capabilities in a variety of configurations, both in process engineering and production engineering.

[0041] Essentially everything from individual sensor / actuator functions to entire plant control functions can be encapsulated as a service.

[0042] A service is a software-implemented function that describes the logic of processing input process variables into output process variables. Thus, a service does not initially have direct contact with the process. Such services that do not have a direct connection with the process to be automated are referred to as service components in the following.

[0043] Service components are implemented with dedicated computing power and are also uniquely addressable.

[0044] Furthermore, the service components have multiple open interfaces for the integration of control components, whose devices are given defined roles in the implementation of the automated functions.

[0045] In summary, service components have the following technical characteristics: -There is no direct connection to the process, only an indirect connection via a connected control component, -The software of the service component is executed on computing resources (embedded devices, PLCs, edge devices), -Standardized communication technologies (e.g., OPC UA Server / Client, OPC UA Pub / Sub, etc.), -Standardized, function-oriented component interfaces (e.g. according to VDI / VDE / NEMUR 2658), The control component as a functional unit is addressable as an entity (e.g. opc.tcp: / / 192.168.2.1:4840 / ns=1:s=Mixing); has. The service component address depends on the underlying communication technology.

[0046] A control component represents an automation device and offers basic functionality (provider).

[0047] A service component represents a higher quality automation function and uses a control component for this purpose (it is a consumer). A service component can also be a higher level automation function that itself uses the service component (hence it is both a service component provider and a consumer).

[0048] The addressing and integration of control and service components is done via a newly introduced integration layer CAML, which implements the provider-consumer mechanism described above. In the following, three advantageously implemented variants are described:

[0049] The provider-consumer mechanism has the following features: - based on standardized communication technologies; - based on standardized interface definitions, - Providers and consumers are uniquely addressable as entities (addressing entities rather than individual signals); - Provider-consumer interactions can be implemented in both one-way and two-way directions. R thing, - depending on the implementation of the interaction, addresses need to be configured on only one side or on both sides; The control component has a provider part; the service component has a consumer part for the connection of a control component and other service components, -The service component also has a provider part, has.

[0050] The above principle of flexible allocation of sensor / actuator logic (encapsulated in control modules) to functional logic (encapsulated in service modules) is used in this architecture as well. In this way, the functionality for accessing distributed peripherals is encapsulated in a control component CC. The program of a service component SC contains a placeholder CCT with a corresponding interface, to which a control component CC can be assigned during the engineering of the system. In this way, it is determined which sensors and actuators should actually be used in the system.

[0051] Component Abstraction and Management Layer As an extension of this approach, it is proposed to introduce a so-called Component Abstraction and Management Layer (CAML), which may be implemented as system functionality, for example in a PLC.

[0052] The new layer CAML allows to encapsulate distributed intelligence and make it available to control programs (such as service components SC) as components with standardized interfaces. In this implementation, CAML is able to perform the following tasks:

[0053] Abstraction functionality: The Component Abstraction and Management Layer CAML constitutes an abstraction layer that is able to abstract the functionality of sensors, actuators and the entire control loop and make them available to the functional logic (in this case the service components SC) as components with standardized interfaces. Here, this abstraction functionality of CAML includes mapping proprietary interfaces to standardized interfaces as required by the control modules, thus creating a CC in terms of abstraction from the CM.

[0054] Here, the standardized interface may have the following form, for example.

[0055] It should be noted here that a CC can encapsulate many different pieces of functionality.

[0056] This includes various sensors (eg for measuring temperature or pressure), actuators (eg for controlling valves or drives) or entire control loops.

[0057] These different types of CCs need to be provided with different interfaces into which the CC functionality can be appropriately abstracted. For this purpose: One The configuration proposes an interface as described in the MTP standard Part 3 [7].

[0058] Table 5.1 provides an overview and according to "Interfaces of Data Objects" in VDI / VDE / NAMUR 2658-3 Interface Family Basic Interface (Extended) Analog value display AnaView, (AnaMon) Analog value operators AnaMan, (AnaManInt) Binary value display BinView, (BinMon) Binary value operators BinMan, (BinManInt) Digital value display DIntView, (DIntMon) Digital Value Operators DIntMan, (DIntManInt) String display StringView Control PIDCtrl Binary Valve BinVlv, (MonBinVlv) Controllable valve AnaVlv, (MonAnaVlv) Binary Drive BinDrv, (MonBinDrv) It is.

[0059] If the control component CC to be embedded is not present in the same controller as the service component SC, the communication with this remotely located control component CC is also abstracted by CAML. In this way, the control component CC can always be controlled in the same way by the service component SC, regardless of how the CC is implemented or in which controller it is implemented.

[0060] Assignment functionality: In architectures known as prior art, the assignment between control modules CM and control module types CMT is determined once during the engineering process and can only be adjusted thereafter by changing the control program. In the new type of architecture proposed in this disclosure, CAML allows a configurable assignment between control modules CC and control module types CCT. In this way, it is advantageous that sensors and actuators integrated in the system can be flexibly reconfigured during plant operation without the need to adjust the control code. For this, a corresponding configuration and runtime interface is required. A prerequisite for this is the addressability of the control components CC.

[0061] Communication Functionality: When a control component CC is not implemented in the same controller as the service component SC with which it is expected to be integrated, communication between these two controllers is necessary. This communication functionality can be undertaken by CAML.

[0062] A mechanism for uniform integration of distributed implementation logic in an automation program is presented, where the functional abstraction of this logic is not based on individual control signals as in the conventional case, but instead components are made available to the automation system with standardized interfaces. These interfaces may be based, for example, on the descriptions in VDI / VDE / NAMUR 2658, PackML or OPC UA companion specifications. With this approach, the modularization concept of process engineering plants, which is already implemented for VDI / VDE / NAMUR 2658 at the level of the entire process functions, is extended down to the field level or individual control level. This also makes the disclosed mechanism different from IEC 61499, which is based only on individual signals and events.

[0063] In summary, it can be said that the subject matter of the claims arises from the following considerations.

[0064] The individual control levels (actuators, sensors, controllers) are separated from the facility control level (automation services).

[0065] It separates the individual control elements (field devices, sensors, actuators, IO stations) from the automation engineering equipment functions, but allows for the separation of the implementation system. The individual control elements can be processed by a programmable logic controller (PLC) separate from the equipment functions.

[0066] The encapsulation of the individual control levels is done using functional interfaces, i.e. traditionally signal integration, and more recently mono integration, i.e. uniquely identifiable physical objects.

[0067] The connection of the individual control elements in today's systems is based on signals. Different devices are connected using a different number of signals (input and output signals). This difference hinders, for example, the interchangeability of sensors and actuators in highly flexible systems. Encapsulation at the functional level requires interfaces that hide the differences at the signal level behind a constant functional interface.

[0068] This interface should ideally be standardized, in this case VDI / VDE / NAMUR 2658-3 would be considered.

[0069] The introduction of an intermediate layer, in the following also referred to as the "Component Abstraction and Management Layer" (CAML), promises to treat so-called "things" on an equal footing with signals.

[0070] Today's systems are subject to dedicated hardware configurations, which in turn derive the information used to configure the deterministic bus system. For more powerful network technologies, IP-based protocols are increasingly used. High flexibility can only be achieved if the tight coupling between hardware and software is resolved. This task is advantageously taken up by the proposed intermediate layer, the Component Abstraction and Management Layer CAML. The Component Abstraction and Management Layer CAML acts as a mediator between facility functions (service components) and the individual control functions (control components).

[0071] In addition, this solution of In an exemplary embodiment,

[0072] The present invention will be described with reference to the drawings. The illustrative embodiments set forth therein are not intended to be limiting of the invention. [Brief description of the drawings]

[0073] [Figure 1]FIG. 1 shows an example plant with a comparison of the OPAS / MTP concepts. [Diagram 2] Figure 2 shows a comparison with the transfer values. [Diagram 3] FIG. 3 shows an architectural variation for implementing CAML. [Figure 4] FIG. 4 shows an exemplary embodiment with two temperature sensors. [Diagram 5] For comparison, FIG. 5 shows an architectural concept according to the prior art. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0074] 1 shows an exemplary automated plant, which consists of a first control loop PCL with a reactor R and a first sensor S1 for measuring the temperature in the reactor, the measurements of which are received by a controller L1. Through a pipeline P, the contents of the reactor R can be pumped by means of a heating device A which increases (or possibly decreases) the temperature of the contents contained in the reactor. This pipeline has a second sensor S2 which is connected to its own controller L2. This is the second control loop SCL.

[0075] In the exemplary configuration, the controller and how the measurement data are used are comparatively arranged. On the left side, the first box OA shows the application according to the above OPAS standard OA. There is an input function block AI, an output function block AO and a control circuit PID.

[0076] On the other hand, on the right hand side, the configuration with the MTP service MS is shown, containing functional blocks that are encapsulated in such a way that they are not accessible from the outside like black boxes, but are only accessible at the functional level, not at the element level.

[0077] The central box 110 shows a solution according to the invention, which also shows that modularity is possible at different levels: the left box S1' relates only to the left sensor S1, the right box SCL' relates to the complete control loop below SCL with further sub-elements AI, PID, AO.

[0078] Figure 2 shows again the same structure of an exemplary automation system including two control loops PCL and SCL, where the boxes OA and MS again relate to solutions according to the OPAS standard (signal oriented) and the respective MTS standard (function oriented).

[0079] On the left are the variables used, e.g. -Value, -Engineering unit, -Range, -Simulation value or -Simulation state, is shown.

[0080] On the right side, the corresponding value -WQC (Worst Quality Code according to Namur standards), -Command, -Procedure, -State, is shown.

[0081] The diagram illustrates the interoperability of the proposed component-focused solution, showing various possible implementations.

[0082] Figure 3 shows three different implementation variants of the CAML approach, which undertake different of the above tasks. Any combination of these variants is possible in the system.

[0083] Here, the sublayers SAL, PAE, PAA and HWC are the same as in FIG. 5 and described above.

[0084] Variant 1: In this variant, the service component SC1 and the integrated control component CC2 are implemented in the same controller. In this case, no communication across controller boundaries is required. On the other hand, it is important to map the CC functionality to a standardized interface and assign it to the desired CCT (CCTb) in the SC. In this way, CAML takes over the abstraction and assignment functionality. This variant is similar to known architectures, with the difference that CAML is added as an abstraction level, which allows a configurable assignment between CCs and CCTs.

[0085] Variation 2: In another variation, a CC (CC1) is shown that is implemented in a different controller than the SC (SC1) with which it is integrated. In this case, the CC (CC 1 In order to exchange data between the CCT (CCTa) and the CCT (CCTa), cross-controller communication (English: cross-controller communication, German: controlleruebergreifende Kommunikation) is required. However, in this variant, this communication is not performed via CAML, but via the provider-consumer approach. The provider-consumer approach provides a provider module (Prov) and a consumer module (Cons). Prov , belowIt has the task of abstracting the functionality of the CC and mapping it to a standardized interface, in case the control module CM does not natively have a standardized interface. Also, Prov and Cons are used to set up the communication connection and thereby provide the CC data in the controller where the SC is implemented. In this case, Cons represents the CC functionality and can be used as if the CC itself was implemented in this controller. This communication is abstracted behind CAML. Also, as in variant 1, CAML is used to abstract the functionality of the CC (CC 1 ) and the CCT (CCTa).

[0086] Variant 3: As in variant 2, also in this case the service component SC1 and the integrated control component CC3 are implemented in different controllers. Therefore, also in this variant a cross-controller communication is required. However, in this case, in contrast to variant 2, this communication functionality is implemented by the CAML itself. In the controller in which the CC is implemented, a CAML is implemented, which maps the CC functionality to a standardized interface, if necessary. This CAML can communicate with the CAML of the controller in which the SC is implemented. In this way, on the one hand, the CAML can abstract the functionality of the CC and make it available to the SC as a component with a standardized interface. This component can then be assigned by the CAML to a CCT, as in the two previous cases. Thus, in this case, the two CAMLs take on both the abstraction and assignment functionality and the communication functionality.

[0087] From the point of view of the main program (in this case the SC), it is not important which of the above variants is implemented in the system. The abstraction functionality made available by CAML in all variants provides the SC with a component with a standardized interface that can be integrated in any case. It is not important for the SC how exactly the CC is implemented, whether it is present in the same controller as the SC (variant 1) or outsourced to another controller (variants 2 and 3). This offers the advantage that a flexible change between the above variants is possible. For example, in case of a failure of a sensor connected inside the controller (variant 1), an external sensor that temporarily or permanently replaces the failed sensor can be connected without any problem, for example with variant 3.

[0088] Configuration and Runtime Interface As mentioned above, in the architecture proposed in this disclosure there is also a configuration and runtime interface that is responsible for parameterizing and tuning the service components. Furthermore, it is necessary to provide an interface that takes care of the configuration of the CAML. This interface is used to determine which control components should be assigned to which CCTs. This interface can be implemented, for example, using an OPC UA server.

[0089] In Fig. 4, an explicit embodiment example is explained in more detail with hypothetical values ​​based on the above-mentioned exemplary plant. In the following, the first temperature sensor CCS1 is replaced by the second temperature sensor CCS1. * It is intended to be reconstructed into

[0090] The configuration is performed by a configuration management tool 400, with the required values ​​provided by configuration files 419 (layer F import / export AML files).

[0091] Two control components, namely Sensor 1 and Sensor 1 *is the control component for the AnaMon provider.

[0092] The control 403 of the "Temperature Control" (SC) method is performed by a Distributed Control Node DCN1 "reactor", which connects with the sensors and controllers DCN3, DCN4 using a suitable interface 411, AnaMon.

[0093] SC Temperature Control Consumer AnaMon-Con.: opc.tcp: / / 192.168.2.50:4840 / ns=3:s=″TREAC″ PIDCtrl-Con.: opc.tcp: / / 192.168.2.50:4840 / ns=3:s=″TREAC″

[0094] The SC Temperature Regulation has an AnaMon consumer to sense the actual temperature at the reactor and a PIDCtrl consumer to control the inlet temperature. Consumer = CC Requirement / Placeholder

[0095] The control component "CC Sensor 1" 401 has providers addressable by: {opc.tcp: / / 192.168.2.10:4840 / ns=3:s=″TI001″}

[0096] Control component "CC sensor 1 * " 402 has providers addressable by: {opc.tcp: / / 192.168.2.11:4840 / ns=3:s=″TI002″}

[0097] The control component "PID Ctrl" 404 has providers addressable by: {opc.tcp: / / 192.168.2.20:4840 / ns=3:s=″TIC101″}

[0098] The service component "temperature adjustment" 403 has two consumers (users) addressable by: -The role of the actual temperature of the reactor AnaMon Consumer 411: {opc.tcp: / / 192.168.2.50:4840 / ns=3:s=″TREAC″} -Reactor inlet temperature role PIDCtrl consumer 412: {opc.tcp: / / 192.168.2.50:4840 / ns=3:s=″TEMPC″} The provider functions of the service are not explicitly shown in the diagram.

[0099] To join a provider-consumer relationship, it is necessary to configure different addresses for the corresponding partners. AnaMon consumer configuration for provider: {opc.tcp: / / 192.168.2.10:4840 / ns=3:s=″TI001″}.

[0100] AnaMon provider configuration for the consumer: {opc.tcp: / / 192.168.2.50:4840 / ns=3:s=″TREAC″}

[0101] Provider's PIDCtrl consumer settings: {opc.tcp: / / 192.168.2.20:4840 / ns=3:s=″TIC101″}

[0102] Consumer PIDCtrl provider settings: {opc.tcp: / / 192.168.2.50:4840 / ns=3:s=″TEMPC″}.

[0103] Thus, the following new relationships were established: The temperature control TREAC uses "TI001". The temperature control TEMPC used is "TIC101".

[0104] In this example, an active bidirectional implementation was chosen, meaning that the consumer and provider each read a value that will be processed by their partner (in OPC UA, reading is an active part of the communication).

[0105] In this way, the relationship can be monitored on both sides. After enabling the interaction, the cascade control of the reactor temperature regulation example worked.

[0106] Generalizing the CAML approach To sum up, it can be said that the CAML approach subdivides the automation software into two parts: the hardware-specific logic (in this case the CC) and the function-specific logic (in this case the SC). CAML basically has the task of abstracting the hardware-specific logic in terms of its concrete form and its implementation location, and making it available to the function-specific logic in the form of components with standardized interfaces. In the present disclosure, one possible implementation of this idea is presented, based on an architecture following the VDI / VDE / NAMUR 2658 guidelines.

[0107] However, the CAML approach is not only applicable to modular plant concepts, the concepts presented in this disclosure also provide added value in traditional PLC programs, allowing a fast, simple and flexible integration into the control code of intelligent devices whose functionality is directly implemented in the field as distributed intelligence.

[0108] Such integration mechanisms for distributed intelligence are pioneering and in line with current trends. For example, the Industrial Internet of Things (IIoT) approach is heavily based on implementing sensor and actuator access logic directly in the field with intelligent devices. Therefore, integrating distributed intelligence in PLC programs is essential. Also, the Open Process Automation Standard (OPAS) [6] is increasingly based on distributing automation functionality in a highly granular manner across a large number of distributed control nodes (DCNs). Distributed intelligence has become the focus and corresponding integration mechanisms are needed.

[0109] Regarding future use of the disclosed concepts in industrial environments, it is necessary to design options that are useful for engineering CAML. This design is still open. One approach is the introduction of new tag types. In modern engineering tools, inputs, outputs and flags are generally available as tag types. In the future, there may be more "component" tag types, which allow to integrate all of the distributed implementations of intelligent components in the field.

[0110] In the introduction to this disclosure, we have shown what challenges exist in modern automated systems with respect to the five enabler features for variability. In the following, we summarize how these challenges can be solved using the approach of this disclosure.

[0111] Abstraction of sensor and actuator access logic and its mapping to standardized interfaces is contemplated. In this way, for example, each valve is represented by the same interface, independent of the detailed implementation of the valve function or the presence or absence of feedback signals. Thus, sensors / actuators of different types (e.g., different valve types) can be integrated into the automation system in the same way, providing interchangeability corresponding to the universality change enabler.

[0112] The sensor and actuator functionality also makes it possible to easily incorporate more powerful or more complex sensors and actuators into an automated system using universal interfaces based on the subject matter of this disclosure, thereby supporting scalability.

[0113] Using a uniform standardized interface (e.g. "one" interface for all valve types, "one" interface for all motor types) also ensures compatibility across different sensor and actuator types.

[0114] The disclosed concept further proposes a distributed implementation of the logic for accessing the sensors and actuators, whereby this logic is implemented directly in the field, for example on a small controller or microcontroller, directly on the sensors or actuators. In this way, the sensors and actuators have all the logic required for their control. This makes it easier to move the sensors and actuators to different locations in the plant, which supports mobility change enablers.

[0115] The CAML approach implements the abstraction of sensor / actuator access logic in standardized components. In this way, the concept of modularity is extended to the field level or individual control level.

[0116] It has become apparent that the problem of change enablers in process plants can be solved based on the concepts of the present disclosure. Thus, variability can be realized not only at the level of modular process units PEA, as described in the architecture concept of VDI / VDE / NAMUR 2658, but also at the level of individual control units, i.e. actuators, sensors and control loops.

[0117] Further advantages become evident in the proposed distributed implementation of the access logic for sensors and actuators, which includes the separation of function-specific logic (e.g. SC) and hardware-specific logic (e.g. CC). This separation provides a number of further advantages:

[0118] The reusability of function-specific logic can be improved, and the updateability of function-specific logic can be improved.

[0119] It allows for greater freedom in configuring hardware or process connections.

[0120] Introducing a separation between device specific logic and function specific logic allows both pieces of logic to be engineered largely independently of each other.

[0121] This allows function-oriented logic to be delivered externally as pre-engineered and pre-tested components.

[0122] Device-specific logic can be pre-engineered and supplied by the device's firmware.

[0123] By implementing function-specific logic on a central computing system (see, for example, OPAS ACP), it becomes possible to implement multiple "virtual" modules / skids / PUs on the hardware, which has the following advantages:

[0124] Costs for the machine builder or module builder are reduced. Flexibility is achieved through scalable PLC resources. Separation of device-specific logic and function-specific logic allows distribution of logic parts to various devices. By distributing part of the logic that was previously implemented on the PLC resources and implementing it on the device resources, the device resources can be used efficiently. In case of a failure, the failed device can be easily replaced.

[0125] The introduction of standardized component interfaces can lead to limitations in the diagnostics of distributed peripherals: only information that is provided in the standardized interface can be read from the components.

[0126] Also, because distributed peripherals can be quickly and easily replaced at runtime, cross-system hardware configuration is no longer feasible at the engineering stage, so new approaches to configuring hardware in such flexible systems need to be created.

Claims

1. 1. A method for connecting a functional control of an automation system comprising at least one physical element (S1, S2, A, R) with said physical element (S1, S2, A, R) by means of at least one automation function, comprising the steps of: said automation system comprises an automation software, which is subdivided into two parts: a hardware specific logic for at least one control component (CC1, CC2, CC3) and a function specific logic for at least one service component (SC), The following steps: - abstracting the functionality of said physical elements (S1, S2, A, R) in said control components (CC1, CC2, CC3) and mapping the real interfaces of said physical elements (S1, S2, A, R) onto previously standardized interfaces, - assigning said control components (CC1, CC2, CC3) to placeholders (CCT) having the same standardized interface as said physical elements (S1, S2, A, R), - encapsulating said at least one automation function in said service component (SC) having at least one first interface (133, 134, 135) to said control components (CC1, CC2, CC3) and at least one further communication interface, - performing communication between said control components (CC1, CC2, CC3) and said service components (SC) or said placeholders (CCT), Equipped with - A method, wherein the configuration of the control components (CC1, CC2, CC3) can be performed by the communication interface (100) at any time during the runtime of the automation system.

2. characterised in that the physical elements (S1, S2, A, R) have the functionality of sensors or actuators in the automation system, The method of claim 1.

3. The standardized interface is defined in accordance with the VDI / VDE / NAMUR 2658 standard. The method according to claim 1 or 2.

4. The communication interface (100) operates in accordance with the OPC UA standard. The method according to any one of claims 1 to 3.

5. characterised in that the service component (SC) has at least one interface to a further service component (SC1) for higher level automation functions, the higher level automation functions having access to lower level automation functions encapsulated in the further service component, The method according to any one of claims 1 to 4.

6. A device (CAML) for linking function control in a distributed automation system with at least one automation function, said automation system having automation software, said automation software being subdivided into two parts, namely a hardware specific logic for at least one control component (CC) and a function specific logic for at least one service component (SC, SC1), The automated system includes physical elements (S1, S2, A, R), - at least one control component (CC1, CC2, CC3) comprising an abstraction of the functionality of said physical elements (S1, S2, A, R) and a mapping of the real interfaces of said physical elements (S1, S2, A, R) to previously standardized interfaces, said control component (CC1, CC2, CC3) being assignable to a placeholder (CCT) having the same standardized interface as said physical elements (S1, S2, A, R), - at least one service component (SC) comprising an encapsulation of said at least one automation function and including at least one interface (133, 134, 135) to said control component (CC1, CC2, CC3) and at least one further communication interface allowing communication between said control component (CC1, CC2, CC3) and said service component (SC, SC1), A device, the configuration of which (CAML) can be performed by means of the communication interface (100) at any time during the runtime of the automation system.

7. characterised in that the physical elements (S1, S2, A, R) have the functionality of sensors or actuators in the automation system, 7. The apparatus of claim 6.

8. The standardized interface is defined in accordance with the VDI / VDE / NAMUR 2658 standard.

8. Apparatus according to claim 6 or 7.

9. The communication interface (100) operates in accordance with the OPC UA standard. An apparatus according to any one of claims 6 to 8.

10. said at least one control component (CC2) and said associated service components (SC, SC1) are implemented in the same controller (110), and communication between said control component (CC2) and said service components (SC, SC1) is performed using interfaces (133, 134) inside the controller, An apparatus according to any one of claims 6 to 9.

11. said at least one control component (CC1) and said associated service component (SC, SC1) are not implemented in the same controller (110), and communication between said control component and said service component (SC, SC1) is performed using a provider-consumer approach via a cross-controller interface, An apparatus according to any one of claims 6 to 9.

12. characterised in that the at least one control component (CC3) and the associated service component (SC, SC1) are not implemented in the same controller (110), and communication between the control component and the service component (SC, SC1) is performed via a controller-wide interface (131, 132, 135), An apparatus according to any one of claims 6 to 9.

Images