Orchestration system for updating containers with applications contained therein, and orchestration method based thereon

Abstract

The invention relates to an orchestration system, in particular for updating containers with applications contained therein, which comprises a number of automation devices (4, 4n) connected to an OT network (20) of an automation installation, each automation device of this number of automation devices being intended and configured to use a container runtime system (5) to host and access at least one application contained within a container (6, 6m). The orchestration system further comprises an update device (1) that is configured to produce an update for the containers (6) and, to this end, is communicatively connected to the runtime system (5) of each automation device (4, 4n) of this number of automation devices, each automation device (4, 4n) of this number of automation devices further hosting a control device (11) for controlling an automation that is to be produced for the automation device (4) as part of the automation installation, and also a server unit (12) that is communicatively connected to the control device (11) and is connected to a client unit (1A) of the update device (1) via a client / server interface (2). The invention also relates to an orchestration method based thereon.

Description

[0001] Orchestration system for updating containers with applications contained therein and orchestration procedure based on this

[0002] Description

[0003] The invention relates to an orchestration system with at least one automation device connected to an OT network of an automation system, which is determined and configured to host and access at least one application contained within a container using a container runtime system, as well as to an orchestration method for updating applications contained in containers.

[0004] As is well known, container technology (“Information Technology”) is now quite widespread in the IT world. For automation devices such as PLCs (Programmable Logic Controllers) or IO modules (Input / Output modules), frequency converters, robots, network devices, power supplies or other components used in automation technology, in particular network components in a system, for which OPC UA (“Open Platform Communications Unified Architecture”; a standard for data exchange as a platform-independent, service-oriented architecture) is now an established standard for modeling and communication, this container technology has not been a topic for very long, but is increasingly gaining acceptance in the automation market. If both technologies, i.e. OPC UA and container technology, are used in an automation device, this has so far happened independently of each other.

[0005] A major advantage of container technology is that, within a runtime system, individual applications, especially software programs, can be isolated from one another in containers and called for processing. Available system resources, especially hardware resources, can be individually and flexibly allocated for efficient use of all resources. For isolated access and individual allocation, such systems typically include a so-called container engine, i.e., dedicated administration and management software. The applications contained in the respective containers therefore usually represent only a small part of a larger application and are often referred to as microservices.Consequently, many containers are often needed to fully deploy a large application. These containers, however, can be flexibly combined and managed—i.e., orchestrated—using simple mechanisms, which is another major advantage of container technology. Since all of this is also useful for the OT (Operations Technology) world, individual automation devices already exist that support container technology.

[0006] In EP 4064637 A1, for example, in order to facilitate the provision of such containers to the user, a method is proposed by which the information required for restarting and executing an application contained in a container can be provided only after the container has been installed in a device intended and configured to execute the application as an edge device and does not have to be known during development.

[0007] The internationally standardized ISA95 model, which divides automation into five levels, serves to differentiate between IT and OT within the scope of this invention. The top two levels comprise the corporate level and the operational management level. The digital processes at these levels are assigned to IT and take place in appropriately configured IT networks. The control of automation processes at the lower three levels—the process management level, the control level, and the field level—is carried out via appropriately configured OT networks.

[0008] Pure container technology is therefore not ideally suited for automation technology. Furthermore, the advantages of container orchestrators in the IT world can also mean disadvantages in the OT world. For example, the OT world requires deterministic behavior, and automatic stopping / starting and updating prevent the secure operation of a machine or system. Machines often cannot be stopped or restarted at any time. In addition, in the OT world, cybersecurity often requires updating the firmware of devices, which often involves rebooting the devices and is not supported by container technology.

[0009] EP 3 998 529 A1 proposes a highly complex container orchestration system for an industrial system comprising a cluster of computer nodes for updating a plurality of control systems for controlling a plurality of operations of a plurality of OT devices, in order to shift operations between control systems and / or OT devices for the update process within a runtime system, so that certain control systems or OT devices can be updated while they are offline and other control systems or OT devices are kept online to perform the respective operations.

[0010] EP 4 064 045 A1 proposes a real-time update of process software with multiple software containers of a deployment unit deployed on a single physical host node.

[0011] Here, a first software container is provided for executing a process application for controlling a process device, a second software container as an execution manager for receiving an updated version of the process application and / or the first software container and a third software container in which the updated version is initialized.

[0012] Subsequently, under the control of the execution manager, an application state of the first process application is determined, this application state is transferred from the first software container to the third software container, an update is then further carried out by means of the third software container using the received application state, and the first software container is then instructed to stop writing output signals for the process device and the third software container is instructed to write output signals for the process device.

[0013] The object of the invention is to show a new technical way with which a respective automation process to be controlled can be easily integrated when updating industrial automation devices of an automation system, such as programmable logic controllers, IO modules (input-to-output modules), frequency converters, robots, network devices, power supplies or other components used in automation technology, in particular in order not to endanger the safe operation of the automation system as a whole by stopping and starting during updates to be carried out.

[0014] The solution according to the invention is provided by a system having the features of claim 1 and a method according to claim 6. Advantageous embodiments of the invention are the subject of the dependent claims.

[0015] Appropriate and advantageous further training is the subject of the respective dependent claims.

[0016] Accordingly, the invention proposes an orchestration system, in particular for updating containers with applications contained therein, which comprises a number of automation devices connected to an OT network of an automation system, wherein each automation device of this number of automation devices is determined and configured to host and access an application contained within a container using a container runtime system.Furthermore, the orchestration system according to the invention comprises a common update device configured to effect an update of the containers, which for this purpose is in communication with the runtime system of each automation device of this number of automation devices, and wherein for this purpose each automation device of this number of automation devices further houses a control device for controlling an automation of the automation device to be effected within the framework of the automation system, as well as a server unit which is in communication with the control device and is additionally connected to a client unit of the update device via a client / server interface.

[0017] By means of such an update device, which is not implemented on a respective automation device itself, but as a common update device for all of the number of automation devices connected to the OT network of an automation system encompassed by the orchestration system, the updating of a large number of containers with applications contained therein, which are hosted in the number of automation devices using a respective container runtime system, can be effected in a coordinated manner, in particular also an update plan stored in the update device can be implemented in a coordinated manner. On the other hand, by means of the client unit set up in the update device, the process control, i.e.In particular, operating states and start and stop processes of a respective control device can be included in the coordination of the update to be carried out. Consequently, it is possible to wait for a point in time at which an update is possible without jeopardizing safe operation and / or to actively intervene in the control of automations to be carried out within the automation system, for example, to transfer the process or the automation system as a whole, or even a sub-process or individual automation devices thereof, to a safe operating state before an update is initiated and thus subsequently carried out.

[0018] Preferably, in such an orchestration system according to the invention, each server unit is furthermore in communication with the operating system of the respective automation device, so that not only the updating of containers, but also an updating of firmware of the respective operating system can be effected in a coordinated and secure manner, in particular in accordance with an update plan stored in the update device.

[0019] Furthermore, the configuration of the server unit as an OPC-LIA server, the client / server interface as an OPC-LIA interface and the client unit as an OPC-LIA client has proven particularly suitable for the orchestration system according to the invention.

[0020] Accordingly, the invention proposes an orchestration method for updating containers with applications contained therein, which are accommodated in a number of automation devices connected to an OT network of an automation system for accessing them using a container runtime system, for which the runtime system of each automation device of this number of automation devices is placed in communication with a common update device configured to effect container updates, and for this purpose, a control device accommodated in each automation device of this number of automation devices for controlling an automation of the automation device to be effected within the framework of the automation system with a server unit to be additionally accommodated in each automation device of this number of automation devices in

[0021] Communication connection is established and connected to a client unit of the shared update device via a client / server interface.

[0022] According to the invention, in order to effect an update of containers with the applications contained therein with respect to at least each automation device of this number of automation devices involved in this process, a first update signal can be sent from the update device for the control device via the client / server interface to the server unit connected thereto and forwarded from there to the control device, specifically to stop the automation to be effected, in particular by controlling the automation of the automation device to be effected within the framework of the automation system to assume a safe state of the automation device or of an area of ​​the automation system extending beyond the automation device,and after feedback to the update device regarding the successful stopping of the automation to be effected, a second update signal is sent from the update device to the runtime system to initiate the update.

[0023] The above-mentioned and further features and advantages of the invention will become more apparent from the following description using examples of preferred embodiments and further developments, with reference to the accompanying drawings, in which:

[0024] Fig. 1 is a highly simplified overview of an exemplary orchestration system according to a preferred embodiment of the invention.

[0025] Reference is made below to Fig. 1, on the basis of which examples of preferred embodiments and further developments of an orchestration system according to the invention, in particular for updating containers with applications contained therein, and also orchestration methods based thereon are outlined and shown in a highly simplified manner for reasons of clarity.

[0026] Fig. 1 shows a highly simplified overview of an orchestration system with a number of automation devices 4, 4n connected to an OT network 20 of an automation system (not shown in detail for reasons of clarity), with the automation device 4n only being shown in outline. As symbolized by the dots to the right above the automation device, in a preferred embodiment, additional automation devices can be connected. The number of such automation devices encompassed by the orchestration system is therefore expediently not just one, but at least two, preferably a greater number. Each automation device 4, 4n of this number of automation devices is, as indicated for the automation device 4, intended and configured to host and access at least one application contained within a container 6, 6m using a container runtime system 5.Since, as described at the beginning, it often takes many containers to fully provide a large application, such automation devices 4, 4n, as indicated in the case of the automation device 4, generally accommodate, in particular also application-related, several containers 6, 6m with applications contained therein for access, in particular in order to be able to be called individually and efficiently for processing, using the container runtime system 5.

[0027] Furthermore, in addition to the number of automation devices 4, 4n, the orchestration system comprises an update device 1, which is configured to effect an update of the containers 6, 6m and, for this purpose, is in communication with the runtime system 5 of each automation device 4, 4n of this number of automation devices, as described in more detail below. The container update is therefore initiated or coordinated from outside the automation devices and not by units hosted by the automation devices.The update device 1 can in particular comprise a control and evaluation unit, in particular in the form of a microcontroller, and a memory device, which can be arranged externally and / or internally to the microcontroller and can comprise software that can contain multiple programs, firmware, and / or an operating system, whereby various protocols, in particular communication protocols, and / or control and evaluation routines can be implemented. An update plan, for example, can also be stored in the memory.

[0028] However, each automation device 4, 4n accommodates a control device 11 for controlling an automation to be effected within the scope of the automation system and, within the scope of the invention, a server unit 12 which is in communication connection with the control device 11 and is connected to a client unit 1A of the updating device 1 via a client / server interface 2.

[0029] If an update of one or more containers is to be carried out, which can be specified in particular manually by a user or automatically, e.g. after certain time cycles and / or according to a stored update plan, or also to the update device by other signaling, whereby the type of specification is not the subject of the invention, the update device 1 is expediently set up to effect such an update of containers 6, 6m with the applications contained therein with respect to at least each container involved, ieIn particular, the automation device of this number of automation devices fundamentally affected within the scope of this update is to send a first update signal AS1 from the update device 1 for the respective control device 11 via the respective client / server interface 2 to the server unit 12 connected to it before initiating the update, which is then forwarded by this to the control device 11, specifically to stop the automation to be effected, ie in particular by controlling the automation of the automation device to be effected within the scope of the automation system in order to assume a safe state of the automation device or, in particular depending on the application, of an area of ​​the automation system going beyond the automation device.

[0030] After feedback RM1 to the update device 1, i.e. in particular from each automation device involved, starting from the respective control device 11 to the server unit 12 connected to it and from there via the respective client / server interface 2 to the update device 1; concerning the successful stopping of the automation to be effected, a second update signal AS2 is then sent from the update device 1 to the respective runtime system 5 to initiate the update.

[0031] As can be seen in Fig. 1, in order to establish the communication connections between the update device 1 and each runtime system 5, two different, complementary or alternative communication connections are generally considered within the scope of the invention.

[0032] On the one hand, the update device 1, in particular the client unit 1A, can be connected to the runtime system 5 via a container interface 14. A second update signal AS2 transmitted via such an additional container interface 14 is labeled AS2' in Fig. 1.

[0033] On the other hand, the server unit 12 can also be connected to the runtime system 5 via a container management interface 10. A second update signal AS2 transmitted via this interface is labeled "AS2" in Fig. 1.

[0034] The interfaces set up for a communication connection can be used to implement the respective communication protocols and to transmit the respective communication signals between the units involved, ie in particular between the update device and the runtime system, the client unit and the server unit, and the server unit and the runtime system, and can be designed to be wireless, e.g. via radio, or wired, e.g. via copper or fiber optics.

[0035] In this case, the interfaces are expediently set up in such a way that, for example, the updating device can query a container status, the updating device 1, expediently in response to its query, can be provided with a container list including the currently running versions, the updating of containers can be initiated, ie in particular can be initiated, containers to be updated can be stopped, ie in particular access to them can be prevented, and / or updated containers can be restarted, ie in particular access to them can be enabled again.

[0036] For the update itself, as is known per se, container images or memory images of the containers intended for an update can be provided on a server 8 serving as a source, e.g. a register server with a plurality of registers or memory areas 8A, wherein the server 8 is in communication with the runtime system 5 for this purpose, in particular via a container register interface 7 configured accordingly as outlined in Fig. 1, in order to transfer corresponding container memory images 9 to it in response to an initiated container update.In addition or as an alternative to this, it can also be provided that such images can be provided in a memory area of ​​the update device 1 itself and transferred from there to the respective automation devices 4, 4n to the runtime systems 5, wherein in the alternative case no separate server 8 serving as a source is required.

[0037] In a preferred embodiment, the update device 1, in order to effect the update, therefore further transmits at least one version designation of a new memory image 9 of at least one container to be updated to the corresponding runtime system 5, in particular as part of the update signal AS2 or by means of a separate communication signal provided for this purpose, but not shown in the figure for reasons of clarity, initiates at least the transmission of the new container memory image 9 of each of the at least one container to be updated to the corresponding runtime system 5, and stops the execution of each of the at least one container 6 to be updated.Depending on the design, the update signal AS2 itself can also comprise corresponding signal parts for initiation and stopping, or at least one further communication signal can be provided, which is not shown in the figure for reasons of clarity.

[0038] The same applies to a preferential starting of the at least one container 6 updated with a new memory image by the updating device 1 after the update has been effected, ie in particular after corresponding feedback from the runtime system 5 to the updating device.

[0039] As further outlined in Fig. 1, in a preferred embodiment of the invention, each server unit is additionally in communication with the operating system 13 of the respective automation device. Consequently, the update device 1, which is jointly connected to the automation devices 4, 4n according to the invention, can preferably not only effect an orderly update of containers, but also a desired or even necessary update of the firmware of the respective operating system. In particular, since, as mentioned at the beginning, OPC UA is an established standard for modeling and communication in automation technology and, as is known, the update of device firmware can already be controlled via this, it has proven particularly suitable for the orchestration system according to the invention to set up the server unit 12 as an OPC UA server, the client / server interface 2 as an OPC UA interface, and the client unit 1A as an OPC UA client.OPC UA and container technology are thus used jointly or complementarily in a particularly expedient implementation of the present invention.

[0040] Following the above-described feedback RM1 to the update device 1 regarding the successful stopping of the automation to be effected, a third update signal AS3 can thus also be sent, for example, from the update device 1 via the client / server interface 2 to the server unit 12 of at least one of the automation devices 4, 4n connected to the OT network to effect an update of its operating system firmware. Consequently, according to a preferred development, a fourth update signal AS4 can be sent from the update device 1 for the control device 11 via the client / server interface 2 to the server unit 12 connected to it, and forwarded by the server unit 12 to the control device 11, specifically to restart the automation to be effected.

[0041] Consequently, by means of the client unit 1A set up in the update device 1 via the server units 12 additionally housed in all accommodated automation devices 4, 4n, not only can the process control, ie in particular operating states and start and stop processes of a respective control device 11, be additionally included in the coordination of the container update to be effected, but preferably also a firmware update can be included in the update process.

[0042] In summary, with a reasonable appreciation of the above description, a possible sequence using an orchestration system according to the invention can be briefly outlined, for example, as follows.

[0043] A list of containers, including the currently running versions, is made available to the update device 1, in particular, depending on the version, either via the client / server interface 2 and container management interface 10 or via the container interface 14.

[0044] If an update is now to be carried out, the update device 1 stops the machine / system via the client / server interface 2 and then also stops the container 6 to be updated, depending on the version, either via the client / server interface 2 and container management interface 10 or via the container interface 14.

[0045] Depending on the implementation, before or after this stopping, the version designation of a new container image 9 is transmitted from the update device 1, in particular from the client unit 1A, to the runtime system 5 of the corresponding automation device 4, 4n, and the transmission of the new image 9 from the storage area 8A of the server 8 to the runtime system 5 of the corresponding automation device 4, 4n is initiated. Depending on the implementation, this can be done either via the client / server interface 2 and container management interface 10 or via the container interface 14.As mentioned above, in addition or as an alternative to this, it can also be provided that such images 9 can be provided in a memory area of ​​the update device 1 itself and from there transferred to the respective automation devices 4, 4n to the runtime systems 5, wherein in the alternative case no separate server 8 serving as a source is required.

[0046] The update device 1 starts the container s with the new image 9, ie, depending on the version, either via the client / server interface 2 and container management interface 10 or via the container interface 14. Of course, several containers s, 6m, even in several automation devices 4, 4n, can be updated accordingly.

[0047] The machine / system starts automatically or is explicitly started by the update device 1 via the client / server interface 2.

[0048] In addition, the update device 1 can also perform a firmware update for the operating system 13 of one or more automation devices 4, 4n, e.g. a firmware update necessary for a container to be updated or already updated, expediently via OPC UA mechanisms already known per se, before new, ie updated containers are started.

[0049] From the above description, it is further apparent that the inventive method is achieved, in particular, by a combination of suitable hardware and software, whereby the required software can also run on existing hardware, for example, an existing processor. However, the programming implementation, in particular the programming configuration of the devices and interfaces involved in the invention, is within the scope of the knowledge and skills of a programmer commissioned to do so, based on a reasonable assessment of the above description.

Claims

Orchestration system, in particular for updating containers with applications contained therein, comprising a number of automation devices (4, 4n) connected to an OT network (20) of an automation system, wherein each automation device of this number of automation devices is determined and configured to host and access at least one application contained within a container (6, 6m) using a container runtime system (5), and an updating device (1) which is configured to effect an update of the containers (6) and for this purpose is in communication with the runtime system (5) of each automation device (4, 4n) of this number of automation devices, wherein each automation device (4,4n) of this number of automation devices further houses a control device (11) for controlling an automation of the automation device (4) to be effected within the automation system, as well as a server unit (12) that is communicatively connected to the control device (11) and connected via a client / server interface (2) to a client unit (1A) of the updating device (1). Orchestration system according to claim 1, wherein each server unit is further communicatively connected to the operating system (13) of the respective automation device. Orchestration system according to claim 1 or 2, wherein the server unit (12) is configured as an OPC-UA server, the client / server interface (2) as an OPC-UA interface, and the client unit (1A) as an OPC-UA client. Orchestration system according to one of the preceding claims,wherein for establishing the communication connection between the update device (1 ) and each runtime system (5), - the server unit (12) is connected to the respective runtime system (5) via a container management interface (10) which is set up for a communication connection between the update device (1) and the respective runtime system, for providing a list of containers including the currently running versions, for querying the container status, for initiating the updating of containers, for stopping containers to be updated and / or for starting updated containers, and / or - the update device (1) is connected to the respective runtime system (5) via a container interface (14), which is configured for a communication connection between the update device and the respective runtime system, for providing a list of containers including the currently running versions, for querying the container status, for initiating the update of containers, for stopping containers to be updated, and / or for starting updated containers. Orchestration system according to one of the preceding claims, which further comprises at least one server (8) in communication with the respective runtime system (5) for providing container memory images (9, 9k).Orchestration method for updating containers (6, 6m) with applications contained therein, which are hosted in a number of automation devices (4, 4n) connected to an OT network (20) of an automation system for accessing them using a container runtime system (5), wherein an updating device (1) is set up to effect an update of containers (6, 6m) with applications contained therein, which are hosted in this number of at least one automation device, and is in communication with the runtime system (5) of each automation device (4, 4n) of this number of automation devices. is provided, and wherein in each automation device (4, 4n) of this number of at least one automation device, a control device (11) for controlling an automation of the automation device (4) to be effected within the framework of the automation system and a server unit (12) are also accommodated, which is put into communication connection with the control device (11) and is connected via a client / server interface (2) to a client unit (1A) of the updating device (1), wherein the method further comprises the steps of effecting an update with respect to at least each automation device (4,4n) of this number of automation devices and before initiating the update, a first update signal (AS1) is sent from the update device (1) for the control device (11) via the client / server interface (2) to the server unit (12) connected thereto and is forwarded from there to the control device (11), specifically to stop the automation to be effected, in particular by controlling the automation of the automation device (4, 4n) to be effected within the framework of the automation system in order to assume a safe state of at least the automation device (4, 4n) or an area of ​​the automation system extending beyond the automation device (4, 4n), and that after feedback (RM1) to the update device (1) regarding the successful stopping of the automation to be effected, a second update signal (AS2',AS2”) is sent from the update device (1) to the runtime system (5) to initiate the update., 7. Orchestration method according to claim 6, wherein the updating device (1) for effecting the update further - a version designation of a new memory image (9) at least of a container to be updated to the corresponding runtime system (5), - initiates the transfer of the new container memory image (9) of each of the at least one container to be updated to the corresponding runtime system (5), and - stops the execution of each of the at least one container (6) to be updated. Orchestration method according to claim 7, wherein, after effecting the update, the updating device (1) further starts the at least one container (6) updated with a new memory image. Orchestration method according to one of claims 6 to 8, wherein, after feedback (RM1) to the updating device (1) regarding the successful stopping of the automation to be effected, a third update signal (AS3) is sent from the updating device (1) via the client / server interface (2) to the server unit (12) of at least one of the automation devices (4) connected to the OT network (12) to effect an update of the firmware of its operating system.Orchestration method according to one of claims 6 to 9, wherein after feedback (RM2) concerning the complete success of all updates to be effected, a fourth update signal (AS4) is sent from the update device (1) for the control device (11) via the client / server interface (2) to the server unit (12) connected thereto and is forwarded by the latter to the control device (11), specifically for restarting the automation to be effected.

Images