CONTAINER-MEDIATED APPLICATION CONFIGURATION

Description

[0001] The optimal use of data is becoming increasingly important for industry. Many companies have already recognized this and are analyzing data from machines and systems on industrial PCs using their own software. This provides valuable insights, but is time-consuming and requires frequent manual intervention to ensure that software, operating systems, and data security are always up to date.

[0002] Time-Sensitive Networking (TSN) refers to a series of standards being developed by the Time-Sensitive Networking Task Group (IEEE 802.1). The standards currently being standardized define mechanisms for transmitting data over Ethernet networks. Many of the projects define extensions to the IEEE 802.1Q bridging standard. These extensions primarily address transmission with very low latency and high availability. An important application area is real-time control streams, which are used for control purposes in automobiles, modern aircraft, and industrial plants, for example.

[0003] Using Industrial Edge, optimal data utilization in the field (i.e., the industrial plant) is easier, more flexible, and more secure. Data is collected and processed directly and securely at the machine, and a central system is available for administration, software provision, and software updates. An Industrial Edge Management System is the central infrastructure used to manage all connected edge devices of all types. Instead of having to install updates and security patches on each device individually, everything is controlled centrally from a single system that can be installed on-site or in the cloud, as needed.

[0004] For example, the well-known open source software "Docker" can be used (but is not limited to) to create and manage containers on edge devices. Thanks to its container visualization, this software offers numerous advantages, such as low resource requirements, rapid deployment, and ease of use. New applications can be developed in any high-level language (C / C++, Java, Python, Node.js), virtualized as a Docker image, and run scalably on all edge devices.

[0005] This requires a suitable runtime environment that defines the available and specified requirements of the runtime system during the runtime of the computer program. This system is defined by the elementary components of the programming language, such as the behavior of language constructs and other functions such as type checking, debugging, code generation, and optimization. The runtime environment also includes the runtime library, standard libraries, programming interfaces, runtime variables, and access to hardware and software components via operating system functions.

[0006] Due to its placement directly in automation systems, the Industrial Edge will also be an attractive platform for TSN-capable Industrial Edge applications in the future, for example, to receive and further process control and machine data via a communication network (e.g. OPC UA PubSub TSN) with guaranteed transmission quality ("Quality of Service", QoS).

[0007] No other technology has shaped IT in recent years as much as container technology. A container acts as a container for applications, including required components such as frameworks or libraries. Similar to the well-known virtualization of different operating systems on a server, containers virtualize applications that are completely agnostic to each other. All virtualized applications run under the same host operating system – this saves data overhead compared to traditional virtualization of entire operating systems.

[0008] Application deployment is simplified by using container technology because containers, which contain all the necessary information, can be easily transported and installed as files. Containers ensure the separation and management of resources used on a computer. A container engine is a piece of software that accepts user requests, including command-line options, retrieves images, and executes the container from the end user's perspective.

[0009] Until now, it has been assumed that a TSN application is packaged in containers in the same way as in virtual machines (VMs). However, each individual TSN application container must contain a complete TSN end device stack. Furthermore, at Industrial Edge, the container host must be equipped with the much more complex TSN stack for switches instead of a TSN stack for end devices. The container host must also be managed as a network infrastructure device.

[0010] If a developer of Industrial Edge applications builds their TSN-capable container applications in the same way that previous automation devices and their firmware or even virtual machines (VMs) were developed, the optimization potential of container technology compared to VM technology is lost. Not only does each TSN application container have to be equipped with a complete TSN device stack, which must be continuously maintained and adapted to new developments, but the host hosting these containers—such as an Industrial Edge—also requires a TSN switch software stack, although technically an end device. A (virtual) TSN switch stack is required to connect the containers within an Industrial Edge with the TSN interface to the automation network. The software stacks required for TSN switches are significantly more complex than end device stacks.In addition, the resource requirements for actually redundant software stacks increase massively when multiple TSN applications are typically used.

[0011] Application developers want to integrate and maintain only the absolutely necessary TSN software in their container applications, not entire TSN device stacks. At the same time, their TSN application containers must be able to dynamically (ad hoc) request TSN streams from the network at any time. To do this, they require topology information from the edge device (such as the device access point(s) to the TSN network(s)) in the simplest possible way.

[0012] Developers and architects of the edge runtime platform ("Edge OS") want or need to keep the software complexity of the edge runtime software - i.e., a container host - low for economic reasons: the use of a TSN switch software stack contradicts this goal and also leads to operational complications for the customer, because a device that is actually used as an end device would simultaneously become part of the network infrastructure device (switching device, bridge, etc.) due to the container technology.

[0013] A peculiarity of the TSN architecture is that TSN applications in end devices must clearly identify and signal their handover point between the application and the network to the TSN network, and in particular to the associated TSN network controller. However, by decoupling the TSN endpoints in containers from the actual network access point ("physical network interface") of an edge end device, it is fundamentally impossible for the TSN applications to signal correct handover points to the TSN network controllers. A normal TSN end device stack in a container would signal the internal container network access, which, however, would be unknown to the network controller – because otherwise, both a complex TSN end device stack (one per container) and exactly one TSN switch stack would be required. State of the art

[0014] "Enabling Multi-Tenant Networks for the Automation Industry", by FRANK REINHARD ET AL, 2019 INTERNATIONAL CONFERENCE ON NETWORKED SYSTEMS (NETSYS), IEEE, March 18, 2019, pages 1-6, XP033622777, DOI: 10.1109 / NETSYS.2019.8854508 discloses a virtual multi-tenant network (VTN) concept that combines network virtualization, hardware virtualization, cloud technologies, and IT automation in such a way that tenants are isolated and configuration changes or security breaches in one tenant do not affect others.

[0015] To date, the TSN environment has assumed that containers can be viewed analogously to virtual machines (VMs). Thus, both containers and VMs correspond to full-fledged TSN endstations ("TSN endstations" according to IEEE 802.1), which requires a corresponding software stack for endstations in each individual container, as described above. Furthermore, similar to virtual machines, a virtual TSN switch, including the necessary TSN switch software stack, is required, only this time in the container host instead of the hypervisor (also called a virtual machine monitor, VMM). This is a class of systems that serves as an abstract layer between the actual hardware (and any operating system already installed on the system) and additional operating systems to be installed.These systems allow the definition of a virtual environment (hardware resources, especially CPU, memory, disk space, available peripherals) that serves as the basis for installing (guest) operating systems, independent of the actual hardware. If the container host is not running directly on the actual hardware, but instead resides in a virtual machine (such as in an industrial edge in a hardware PLC / programmable logic controller), resource consumption increases further because both the hypervisor and the container host each require a complete TSN switch software stack.

[0016] One such infrastructure is described in the article "Enabling Multi-Tenant Networks for the Automation Industry" by Reinhard Frank, Florian Zeiger, Matthias Scheffel, and Hals-Peter Huth at the 2019 International Conference on Networked Systems (NetSys). This article describes a solution for integrating OEM devices into an industrial network using a so-called Virtual Tenant Network. Typically, information (especially regarding Layer 2 interconnectivity) is defined during the engineering process. This is inflexible, especially when additional services are added later.

[0017] It is therefore an object of the invention to provide a technical solution for containerized TSN applications in which, on the one hand, the application does not require a complex TSN stack and, on the other hand, the respective container host (Industrial Edge, cloud cluster node, etc.) only acts as an end device and not as a network infrastructure component.

[0018] It is also an object of the invention to support the network separation typical for automation technology and thus more than one TSN network access and to protect application developers from the resulting complications.

[0019] The problem is solved by a method according to the features of patent claim 1.

[0020] The object is further achieved by a computer program product suitable for carrying out the steps according to the method according to patent claim 5.

[0021] The claimed method enables the configuration of an application which is introduced into a device for later execution by means of a container, wherein the device has an access point via which it is connected to a communication network, and the container has a container access point with a first address.

[0022] For the container access point, an associated device access point is determined with a second address ("ens33"), and for the first address of the container access point and the second address of the associated device access point, a third address is determined, transmitted by an Industrial Automation Management Entity which is connected to the access point of the device via the communication network to the application and configured for the access points using the address information thus obtained, so that access to the communication network via the access point of the device is enabled.

[0023] The object is also achieved by a device according to the features of patent claim 6.

[0024] The TTIP device according to the invention supports the configuration of an application in a device having an access point via which the device is connected to a communication network with a first address ("ens33"), wherein the application is introduced into the device by means of a container, and the device is intended and suitable for executing the application as an edge device, and the container has a container access point with a second address ("eth0", NAP-ID).

[0025] The device (TTIP) determines an associated device access point with the first address for the container access point and stores this address. The device (TTIP) determines a third address (IP address) for the second address of the container access point and the first address of the associated device access point. This address is a TSN Domain Management Entity (TDME, formerly Industrial Automation Management Entity IAME), which can be connected to the access point (NAP) of the device (DEV) via the communications network (T-NET). The device (TTIP) transmits this obtained address information to the application for configuration and to enable it to access the communications network via the device's access point.

[0026] Further advantageous embodiments are specified in the subclaims.

[0027] The container first connects to a virtual switching node within the device via its container access point via a virtual switching network in order to receive the required configuration data.

[0028] In another preferred embodiment, managed object information associated with the device access point is determined based on existing topology information about the communication network. This is advantageous because this information is usually available and therefore does not need to be additionally provided for configuration.

[0029] According to an advantageous embodiment, the device contains a container engine that provides information about the device's internal path from the network access point to the container with the application. This is particularly advantageous when the inventive method is applied with already known implementations of container technology, such as Docker, which is familiar to those skilled in the art. In this case, a container engine is already provided and only needs to be upgraded for the inventive method to provide the desired information.

[0030] The method according to the invention can be implemented over the communications network (T-NET) using Time-Sensitive Networking according to the IEEE 802.1 standard. Advantageous effects are described below.

[0031] The configuration information can be transferred to the application, for example, using an environment variable or a configuration file. This approach proves advantageous because it allows for the use of already known mechanisms, thus eliminating the need to modify the underlying technology more than necessary and adapt it to the method according to the invention. Character description

[0032] The invention is explained in more detail below by the figures, in which Figure 1 a schematic comparison of containerized applications according to the prior art and according to the invention, Figure 2 an overview of an exemplary structure of the network elements according to the invention, Figures 3 to 6 the information flow in the network element according to the invention and Figure 7 the flow of information in time between individual network elements according to Figure 2 .

[0033] The Figure 1 illustrates the advantageous difference already described above between the known prior art and the solution according to the invention. The upper box 101' shows an arrangement according to the prior art, of a system with two exemplary TSN applications TSN App1, TSN App2, which, as described above, are delivered in such containers. The number of applications listed here should not be restricted to two; any number is conceivable. Each container must currently also contain a TSN device stack TSN DS1, TSN DS2 as the software responsible for the terminal device control plane of TSN. The system also contains a TSN bridge stack, TSN BS, for carrying out the necessary switching tasks, i.e. the software responsible for the control plane of the TSN bridges.

[0034] One disadvantage of previously redundant software is obvious to the expert: the code used becomes unnecessarily bloated, the installation and maintenance effort is significant, and errors can creep in (for example, due to outdated or different versions of individual applications). The applications do not have to be from the same provider or installed on the system at the same time.

[0035] The lower box 100 now shows, by comparison, the situation when proceeding according to the invention: no stack is required in the containers of the two TSN applications TSN App1 and TSN App2, so these containers can remain lean; it is sufficient to "package" the actual application. It is sufficient for the TSN DS communication stack to exist once in the system.

[0036] In the Figure 2the invention with its affected components and the information exchanged is explained in more detail.

[0037] The task is solved by a new component in the network, hereinafter also called "TSN Topology Information Provider Module", TTIP, 400.

[0038] The novel component, "TSN Topology Information Provider" module TTIP, determines the ISO / OSI Layer 2 network interconnection for each container CTR, 301 with TSN application TAPP during its setup by the container runtime system, determines the topological information of the associated external network access point NAP, 101, 101a of the container host and the responsible Industrial Automation Management Entity IAME, 202, and provides this information in a form to the respective container CTR, 301 so that the TSN application located therein can now successfully reserve (create) TSN streams in the TSN network.

[0039] As soon as a container CTR, 301 is to be newly set up and networked with a TSN application TAPP, the new component TTIP, 400, is integrated into the process. The TTIP component now requires (directly or indirectly) information, 304, 305, from the Container Engine CE, 300, about which TSN interface(s) NAP, NAP' of the device DEV, 100 the container with the TSN application CTR, 301 should be connected to on the data link layer (layer 2). Depending on the automation network, the device DEV, 100 can also have more than one NAP, NAP' 101.

[0040] In the case of the Industrial Edge, the assignment of the CTR container (with the TAPP application contained therein) to the NAP, NAP' interface cannot be defined in advance by the application developer and stored in his TAPP application, since the developer cannot know either the specific target hardware and thus its specific interface identifiers (for example, "ens33" or "enp0s3", see the explanations below) or the user's desired assignment to one or more automation networks.

[0041] The "first" or "second" interface may be known (for example, "ens33" or "ens34"), but has the user selected "ens34" or "ens33" for this application?

[0042] A container CTR, 301 is therefore usually only connected to a virtual TSN switch VTS, 102 via a virtual container network VCN, 303, upon its actual startup with its own container-local access point CNAP, 302 (in the example, "eth0" or "tsn0"). The information required for the subsequent connection of the container CTR, 301 to a specific network comes from the configuration of the device DEV and, in particular, the Industrial Edge runtime environment. The virtual TSN switch VTS, 102 is, in turn, connected internally to the network access point NAP, 101 or NAP', 101a, which forms the respective TSN access of the device DEV, 100, to the external communication network TSN network T-NET, 666. It is irrelevant whether the virtual TSN switch VTS, 102 is an independent virtual (software) component or forms part of the hardware and firmware of the network access point NAP.

[0043] The use of the new component "TSN Topology Information Provider" module TTIP, 400 is particularly advantageous for the network separations typical for automation technology, where a single automation device (and often Industrial Edge devices) is connected to more than one network at the same time.

[0044] In the case of the Industrial Edge described above, the appropriate runtime environment ("Industrial Edge Runtime" software) as an application orchestrator in a device DEV, 100, generates the final container and network (VCN) configuration when an application is started and passes it on to the Container Engine CE, 300.

[0045] Orchestration (English orchestration , instrumentation, staging) refers to the flexible combination of several services into a composition. https: / / de.wikipedia.org / wiki / Dienstekomposition

[0046] This information, in addition to the network assignment, is also available to the new component, "TSN Topology Information Provider" module TTIP, 400, so that the concrete system-specific name of the network access point NAP, 101 (for example, in the form of the name or index of the relevant interface / network interfaces) is known ("ens34").

[0047] Furthermore, the TSN Topology Information Provider module TTIP, 400 determines the "Industrial Automation Management Entity", IAME, 202, responsible for the network access point NAP, 101 and the underlying communication network T-NET, 666. To do so, the TSN Topology Information Provider module TTIP accesses the topology information provided by the operating system about the device-internal virtual networks, if certain implementations of a Container Engine CE, 300 do not have complete information about the virtual networks.

[0048] The respective responsible Industrial Automation Management Entity IAME, 202 has identified itself to the discovered end devices as part of its network discovery by using mechanisms defined in TSN specifications (DISCovery & IFC Interface Configuration, 212) to set, among other things, a so-called Managed Network Object MNO, 220, with its IP address, for example via the "netconf" protocol (according to RFC 6241).

[0049] The TSN Topology Information Provider module (TTIP) uses the previously determined information (401) to decide which Managed Network Object (MNO) with an IAME address it must specifically read (402): the selection criterion here is the network access point (NAP) identification (name, index, etc.). Using this IP address, a TSN application (TAPP) (201) can later reserve or request one or more TSN streams from the Industrial Automation Management Entity (IAME) via the "add stream" service (AS) (211).

[0050] The TSN Topology Information Provider module TTIP then provides the information on the network access point NAP and Industrial Automation Management Entity IAME as a data record (403) to the TSN application (201) in the TSN container (301). This data record can, for example, look like this: tsn: nap: "ens34" iame: "192.168.6.66"

[0051] Provisioning can be done in various ways, for example using so-called "environment variables" for the processes started in the container or via an ad-hoc configuration file with the data set, 403, that is inserted ("mounted") into the container.

[0052] This second form of provisioning can also react to changes in the TSN network, for example, if the relevant Managed Network Object (MNO) 220 needs to be subsequently modified during application runtime and a restart of the TSN container is undesirable. The TSN application TAPP 201 can monitor the data record (403) using common OS methods for notifying file changes. In addition, the TSN Topology Information Provider Module TTIP monitors the relevant Managed Network Object (MNO) 220 for changes 212 through an Industrial Automation Management Entity (IAME) 202.

[0053] A TSN application TAPP, 201, in turn, requires the data record 403 in order to establish a communication connection 404 to the TSN Stream Service API of the Industrial Automation Management Entity IAME, 202 and subsequently to set up or reserve TSN streams. The IP address of the Industrial Automation Management Entity IAME is used to establish the connection. The network access point NAP identification is then transmitted as a parameter of a TSN stream reservation AS, 211 so that the Industrial Automation Management Entity IAME can configure the stream through the communication network T-NET, 666 to the correct network access point NAP, 101. The Container Engine CE, 300 has already provided the basic internal path from the network access point NAP to the container CTR in the TSN application TAPP, 401. An automatic stream configuration of the internal virtual TSN switch VTS, 102 can be provided.

[0054] The Figure 3shows a process that runs in the innovative TTIP module. Starting from a start state 901, a first step checks whether an MNO with an IAME network address has been set or changed, 902. If this is the case, Y, a (not yet detected) TSN application container is determined in a second step, 903.

[0055] Then the address information required to start the TSN application container is determined, 903, the process steps carried out here are described in Figure 5 explained in detail. After completing the run, the system returns to exit point A.

[0056] The result after running through this subroutine A is a list of tuples that contain information about the container access point CNAP, the responsible network access point NAP and the IAME address, 904. A container can also have more than one access point CNAP, for example, if connected machines from completely separate TSN networks are to be addressed, although this is not shown in the figure.

[0057] In a next step, the (first) new or modified TSN application container thus identified is restarted or configured, B. The necessary steps are described in more detail in the Figure 6 shown.

[0058] Finally, a check is made in step 905 to determine whether there are any additional TSN application containers. If this is not the case (N), the routine returns to the beginning and starts again with step 902. If there are additional containers, query 901 is skipped and the program continues with the first subroutine 903.

[0059] Figure 4 shows a further process flow in the new TTIP module, which assumes that a new TSN application container has been started or an (old) container has been restarted, 912. If this was the case, Y, then the TSN application container is determined again in a further step, 903.

[0060] Then the address information required to start the TSN application container is determined, 903, the process steps carried out here are, as mentioned above, in Figure 5explained in detail. After completing the run, the system returns to exit point A.

[0061] In the next step, the information thus determined (TSN application container - IAME tuple) is published 913, in the example presented either as a "configuration file" with the determined tuples (container access point CNAP, network access point NAP, IAME address), which is written (see step 914). Alternative solutions are conceivable (step 915), for example, passing an environment variable to the environment of the (new) container with the TSN application. https: / / de.wikipedia.org / wiki / Umgebungsvariable

[0062] In Figure 5 is the sequence of the first subroutine 903 from the Figure 3 and 4 explained: In a first step, the container access point(s) CNAP for the container CTR containing the TSN application are determined by querying the Container Engine CE, 921.

[0063] In a second step, the (respective) path from the container access point to the connected network access point NAP is determined, 922.

[0064] In a third step, at least one associated Managed Object MNO is determined for the network access point NAP, 923.

[0065] In a fourth step, the associated IAME address can be found using the Managed Object MNO, 924.

[0066] The result is then the tuple (CNAP, NAP, IAME address), as described above, 925, with which one can access the respective routines from Figure 3 or 4 can jump back again.

[0067] In Figure 6 is the sequence of the second subroutine 904 from the Figure 3 and 4explained: In a first step 931, the information determined from the first subroutine is published, 913, the configuration data is overwritten with the newly determined information (CNAP, NAP, IAME address), 914 and the container CTR is restarted with the TSN application TAPP, 915, see analogous to Figure 4 .

[0068] Figure 7 takes up the procedure described above from a different perspective and shows the exchange of information between the individual components from the Figure 2 over time t.

[0069] First, for example, a new container CTR, 201, is introduced (symbolized by the star). The container access point CNAP (called "eth0" in the example, as described above) is forwarded to the virtual container network VCN, 303. The associated access point NAP, 101, of the device DEV to the communication network T-NET, 666 (in the example, "ens33") is forwarded to the Container Engine CE, 300. This information is stored in the new network element TTIP, 400.

[0070] In parallel, the IAME, 202 as a Managed Object MNO has stored the IP address under which it can be reached via the T-Net communication network (not shown in the flow chart).

[0071] The new network element now recognizes the related tuples (CNAP, NAP, IAME address), as described above in the Figures 3 to 6 described, and passes this information on to the container CTR, 201 with the TSN application TAPP.

[0072] In the next step, the application can then use this information to connect to the Industrial Automation Management Entity IAME.

[0073] The described method and device enable simplified TSN application development with minimal software effort, thus enhancing the industrial edge ecosystem, and in particular the runtime platform. This is achieved in particular by freeing developers of TSN applications (containers) from the need to license, integrate, and maintain complete TSN device stacks.

[0074] Operators and developers of edge devices are exempted from having to additionally equip these devices as infrastructure devices in the form of TSN switches (software stack).

[0075] Operators of edge devices can integrate them purely as end devices into their customer systems, rather than additionally as network infrastructure components (TSN switches).

[0076] Advantageously, the internal virtual TSN communication structure remains hidden from the TSN system network; this avoids, for example, the situation where starting and stopping TSN application containers leads to unnecessary replanning runs of TSN network controllers or pairwise update processes between individual TSN switches.

[0077] By simplifying the development of TSN-enabled edge applications, they can be offered more cost-effectively, thus reducing the entry barrier for the development of new TSN applications.

Claims

1. Method for configuring an application (TAPP), wherein the application is introduced in a device (DEV) by means of a container (CTR), and the device is intended and suitable for executing the application (TAPP) as an edge device, the device has an access point (NAP) with a first address ("ens33"), and is linked to a communication network (T-NET) via said access point using the Time-Sensitive Networking standard in accordance with IEEE 802.1, and the container (CTR) has a container access point (CNAP) with a second address ("eth0", NAP-ID), wherein the device (DEV) has a container engine (CE), which provides information about the device-internal path from the network access point (NAP) to the container (CTR), and with respect to the container access point (CNAP) with the second address, the associated device access point (NAP) is determined with the first address ("ens33"), and with respect to the second address of the container access point (CNAP) and the first address of the associated device access point (NAP), a third address (IP address) managed object information (MNO) associated with the device access point (NAP) is determined on the basis of topology information about the communication network. is determined, of an industrial automation management entity (IAME) connected to the access point (NAP) of the device (DEV) via the communication network (T-NET), and the application (TAPP) is configured by means of the thus obtained address information, consisting of - the second address of the container access point (CNAP), - the first address of the access point of the device (NAP), and - the third address of the connected industrial automation management entity (IAME), for the access points by assignment of the second address ("eth0", NAP-ID) and is upgraded for the access to the communication network (T-NET) via the access point (NAP) of the device (DEV).

2. Method according to Claim 1, wherein the container (CTR) is connected via its container access point (CNAP) firstly via a virtual switching network (VCN) to a virtual switching node (VTS) within the device (DEV).

3. Method according to either of the preceding claims, wherein the configuration information is transferred (914) to the application (TAPP) by means of an environment variable.

4. Method according to any of the preceding Claims 1 to 3, wherein the configuration information is transferred (915) to the application (TAPP) by means of a config file.

5. Computer program product for carrying out the steps of the method according to any of Claims 1 to 4.

6. Apparatus (TTIP) for supporting a configuration of an application (TAPP) in a device (DEV) having an access point (NAP), via which the device (DEV) is linked to a communication network (T-NET) using the Time-Sensitive Networking standard in accordance with IEEE 802.1, with a first address ("ens33"), wherein the application (TAPP) is introduced in the device (DEV) by means of a container (CTR), and the device is intended and suitable for executing the application (TAPP) as an edge device, and the container (CTR) has a container access point (CNAP) with a second address ("eth0", NAP-ID), the apparatus requests access information about the device-internal path from the network access point (NAP) to the container (CTR) with the application (TAPP) from a container engine (CE), wherein the apparatus (TTIP) is designed for determining and storing a device access point (NAP) associated with the container access point (CNAP) with the first address ("ens33"), and the apparatus (TTIP) is designed for determining a third address (IP address) with respect to the second address of the container access point (CNAP) and the first address of the associated device access point (NAP), with respect to an industrial automation management entity (IAME) connected to the access point (NAP) of the device (DEV) via the communication network (T-NET), by virtue of the fact that the apparatus (TTIP) requests address information with respect to the device access point (NAP) from associated managed object information (MNO) which was determined on the basis of topology information about the communication network, and the apparatus (TTIP) is designed for communicating this obtained address information to the application (TAPP) for configuration purposes, consisting of - the second address of the container access point (CNAP), - the first address of the access point of the device (NAP), and - the third address of the connected industrial automation management entity (IAME), and by assignment of the second address ("eth0", NAP-ID) upgrades it for the access to the communication network (T-NET) via the access point (NAP) of the device (DEV).

7. Apparatus according to Claim 6, wherein the apparatus (TTIP) accesses the container (CTR) via the container access point (CNAP) thereof firstly via a virtual switching network (VCN) to a virtual switching node (VTS) within the device (DEV).

8. Apparatus according to either of the preceding Claims 6 and 7, wherein the apparatus (TTIP) transfers the configuration information to the application (TAPP) by means of an environment variable.

9. Apparatus according to any of the preceding Claims 6 to 8, wherein the apparatus (TTIP) transfers the configuration information to the application (TAPP) by means of a config file.