EP4338050A1

EP4338050A1 - Management of runtime containers for an industrial automation system

Info

Publication number: EP4338050A1
Application number: EP22728819.8A
Authority: EP
Inventors: Thomas Holm; Jan JENKE; Nikolai FALKE
Original assignee: Wago Verwaltungs GmbH
Current assignee: Wago Verwaltungs GmbH
Priority date: 2021-05-11
Filing date: 2022-05-11
Publication date: 2024-03-20
Also published as: US20240077856A1; CN117296044A; DE102021204757A1; WO2022238482A1

Abstract

The invention relates to a method in an industrial automation system, said method comprising: transmitting an input data set (210) from an industrial control device (300) to a container manager (100), the input data set (210) comprising at least input metadata; using the container manager (100) to determine, based on the input metadata, a runtime container (400) for processing input data; using an application of the runtime container (400) to generate output data based on the input data; generating an output data set (220) using the container manager (100), the output data set (220) comprising at least output metadata; and transmitting the output data set (220) from the container manager (100) to the industrial control device (300).

Description

1

Management of runtime containers for an industrial automation system l. technical field

The invention generally relates to the field of industrial automation technology and in particular to methods and techniques for dynamic management of runtime containers for operating an industrial automation system.

2. Background

Techniques are already known in the field of general information technology (IT) for developing applications quickly and independently of the underlying hardware infrastructure. For example, approaches such as "Continuous Deployment" are used to implement complex software projects in widely distributed

to manage computer infrastructures. These approaches are typically supported by software applications encapsulated in so-called "containers". In contrast to virtual machines, these virtualize the operating system instead of the hardware and thus enable software to be designed in a portable and efficient manner. One technology that is often used is Docker technology, for example, which is primarily geared towards virtualization with Linux.

In another technical field, namely industrial automation technology (AT), these approaches have hardly been used to date. On the other hand, in the course of the fourth industrial revolution and the all-pervading digitization, cloud solutions are also increasingly being used in industrial automation technology for analysis, administration and sometimes even for controlling the components of automation environments. In this case, data is usually generated by industrial control devices at runtime and sent to one or more cloud systems. An industrial control device can be a programmable logic controller (PLC), for example. Such a device is typically communicatively connected and implemented with one or more sensors and/or actuators 2

Tasks in the context of automation technology. Within the scope of the invention, a cloud system can generally include a computer system that is remote from the control device. Examples include the WAGO Cloud, Microsoft Azure, Amazon AWS (“Amazon Web Services”), the SAP Cloud or the IBM Cloud. Within the cloud system, the received data is usually stored, evaluated and/or made available to users prepared for any end device.

For example, a system for executing a closed control loop on data for cloud-based applications is known from EP 3249481 Bi. It describes how an industrial controller interacts with a cloud environment and forms a closed loop to perform complex calculations in a cloud without burdening the industrial controller. This is achieved in that so-called cloud variables are generated in the controller, which are forwarded by a cloud agent in the controller for processing in the cloud. However, EP 3 249481 Bi considers the processing logic on the industrial controller and the cloud application to be monolithic components that hardly affect one another.

The present invention is therefore based on the problem of providing methods that allow an industrial control device to access external resources more flexibly.

3. Summary of the Invention

This problem is solved by the subject matter of the independent patent claims, with the subclaims relating to preferred developments.

Claim 1 relates to a method in an industrial automation system. An industrial control device sends an input data set to a container manager, the input data set comprising at least (or only) input metadata. Based on the input metadata, the container manager determines a runtime container for processing input data from the industrial control device. Output data is generated based on the input data by an application of the runtime container. The container manager creates an output data set, the output data set including at least output metadata. The container manager sends the output record to the industrial control device. 3

In a particularly simple implementation, the input data to be processed can be sent directly in the input data record from the industrial control device to the container manager, which can then send them to the runtime container. In this embodiment, however, the data exchange via the container manager can represent a bottleneck in terms of data transmission, which can increase the communication effort. It is therefore alternatively provided that the container manager can send an address of the runtime container to the industrial control device. Optionally, an address of the industrial control device can be communicated to the runtime container. This can be contained in the metadata of the control device or alternatively be determined by the container manager. The input data can then be passed from the industrial controller directly to the runtime container (i.e. without the involvement of the container manager) and optionally an address of the controller can be passed.

There are also two options for communicating output data.

In a simple implementation, the runtime container can send the generated output data to the container manager, which in turn sends it to the industrial control device in the output data set. This results in the same disadvantages with regard to the container manager as a bottleneck as already described on the input page. Alternatively, it is therefore provided that the runtime container can send the output data directly to an address of the control device. The address can either be known directly from the control program or through the container manager.

Of course, both approaches described above can also be mixed, i.e. the communication of the input data can take place via the container manager, with the output data being transmitted directly, and vice versa.

The invention thus deals with a method and devices in which an industrial control device, in particular a function module thereof, for example from an IEC programming, preferably IEC 61131, is set up in such a way to access external resources.

In general, exemplary embodiments of the invention include the orchestration, ie starting, configuring, monitoring and/or stopping of (software) applications encapsulated in containers from an industrial controller, preferably by the 4

Control logic of the real-time system located on the industrial controller. The (software) application encapsulated in a container can also be run on a different hardware infrastructure (e.g. in a cloud).

Due to the possibility of starting, monitoring and/or stopping (software) applications encapsulated in containers from the PLC program of the industrial control device, the systems (IT and AT) are further combined with one another. Furthermore, software components can be dynamically loaded, switched off and/or removed from the PLC program by using container technologies. The latter enables a consistent utilization of the memory. In addition, the outsourcing of software applications encapsulated in containers offers a bridge between software components that have been implemented in different programming languages and software platforms.

A method which is carried out by a container manager in an industrial automation system is also provided. This method comprises: receiving an input data set from an industrial control device, the input data set comprising at least input metadata; determine, based on the input metadata, a runtime container for processing input data; generating an output data set, the output data set comprising at least output metadata; and sending the output data set to the industrial control device.

A corresponding method, which is carried out by an industrial control device in an industrial automation system, comprises: Sending an input data set to a container manager, the input data set comprising at least input metadata, the input metadata allowing the container manager to use a runtime container for generating output data determine based on input data; receiving an output record from the container manager, the output record including at least output metadata.

In another aspect of the invention, the input metadata may include a container type. The developer of the runtime program on the industrial control device can use the container type to define which functionality is to be swapped out in a container. 5

The input metadata may also include an input identifier, such as a timestamp, where the output data set includes output metadata, and where the output metadata includes the same input identifier as the associated input metadata. This serves to associate the output data produced by the container with the original input data (e.g. by a timestamp). This enables synchronization despite the asynchronous mode of operation.

Further, the input metadata may include a return address, a container identifier, and/or a policy. A policy can define the conditions under which a new container is to be started, an existing container is to be restarted, stopped and/or removed, and allows the control device or its programmer extensive control over the container.

If the output dataset includes output metadata, it may also include a status.

Designating a runtime container to process the input data may include starting a new runtime container or selecting an already running runtime container.

Furthermore, determining a runtime container for processing the input data can be based on a current utilization of processing resources for operating runtime containers.

The invention further provides a system in its entirety and the above-mentioned devices, each with means for carrying out the methods described herein. A computer program is also provided with instructions for implementing the methods described herein.

4. Short description of the drawings

Preferred exemplary embodiments of the present invention are explained below with reference to the accompanying figures:

Fig. 1: A schematic representation of a system environment for a first

embodiment of the invention. 6

Fig. 2: A schematic representation of a system environment for a second

embodiment of the invention.

5. Detailed Description of Preferred Embodiments

In the following, currently preferred exemplary embodiments of a method according to the invention for operating an industrial automation system are explained in more detail.

Two exemplary embodiments of an automation system are shown in FIGS. In both embodiments, the system comprises an industrial control device 300, which can be, for example, a programmable logic controller (PLC). Such a device 300 is typically communicatively connected to one or more sensors and/or actuators and implements tasks in the context of automation technology. An input process image 310 can be created from the sensor data and an output process image 330 can be generated by appropriate processing.

A function module (see the module “FUB” in FIG. 1) 320 for communication with the container manager 100 is configured within the control logic of the industrial controller 300 . Data from the control logic can be selected via the module 320 and forwarded to the container manager 100 in a predetermined format as an input data record 210 (see the “input packet type 1” in FIG. 1 and the “input packet” in FIG. 2).

Such input packets 210 include at least input metadata in both embodiments (FIGS. 1 and 2). This input metadata can include:

- A selected container type, which specifies the type of container that is to provide the desired functionality (eg specific algorithm). The container type can either be specified by the function module 300 or, in the case of a generic function module 300, specified by the user. Examples of container types can be: anomaly detection algorithms, prediction functions, procedures for phase analysis of the power consumption of cyclic/periodic processes, neural networks, trend/drift detection, dashboards, data loggers and/or programs from other companies in a defined container. 7

- A unique input identifier (see "Input ID" in Fig. 2) in order to be able to assign the output to the input packet and the function module later on.

- A return address (if required).

- A container identifier (see "Container ID" in Fig. 1 and 2; optional and depending on the specific implementation).

- An optional policy with one or more variables. Such policies can define, among other things, under what conditions a new container is started, an existing container is restarted, stopped and/or removed.

Example 1: As soon as no more data is sent to the container for a defined period of time, it is terminated.

Example 2: As soon as no more data is sent to the container for a defined period of time, it is removed.

Example 3: The container is never terminated and deleted except by an explicit command.

Example 4: The container can be used by several FUBs + combinations with example 1-3.

Example 5: The container can only be used by one FUB + combinations with example 1-3.

It goes without saying that in alternative embodiments only subsets of the above data can also be used as metadata.

In the embodiment according to FIG. 2, the input packet 210 also includes the actual input data from the control logic (hereinafter also referred to as “input data”), ie the data that is to be processed. In the embodiment according to FIG. 1, on the other hand, the input data are sent separately from the control device 300 to the corresponding container 400 (see the "input packet type 2" 215 in FIG. 1). 8th

An example implementation of data communication in JSON format is described below:

First connection to the container manager:

json

Topic: Container Manager

Payload: { 'returnAddress': '...', 'containerType': policy: ', 'containerConfig': , 'projectID':

}

Message from container manager to FUB - Permanent subscription of the FUB to get status changes. Container manager provides permanent status information, so that the FUB can derive actions when no more status information comes:

Topic: 'pfcldl/instanceldl'

Payload: {'time': 'containerStatus':

'inputAddress': 'outputAddress': ,

}

Data from FUB:

Topic:

payload: {

'data': [{'time': '2020-06-29T09:09:54.874Z', 'valuel':

1.2, 'value2': 1.4, ...., 'xyz' : [221, 213, 213]}],

'outputAddress': ,

'sourcelD':

}

Data from the model:

Topic: 'Pfcldl/Instanceldl/output'

payload: {

'data': [{'time': '2020-06-29T09:09:54.874Z',

'resultl':1.23, 'result2':2.34}],} 9

The task of the container manager 100 is to manage the available containers 400, taking into account the available resources, and to forward the incoming input packets 210 to the containers 400. When the container manager 100 receives a new input 210, it decides whether to start a container 400 based on the container type, the policy and/or the container ID. If no container exists yet for the requested container type, a container of this type is typically started. If a container already exists and the policy allows the use of a "shared" container, this can be used. A ContainerID can be used to specify that exactly one container with this ContainerID is used. If this already exists, it will be used, otherwise a new container will be started with this ContainerID. Other rules can be adjusted depending on the application.

In the embodiment of FIG. 2, the input data is forwarded to the appropriate container 400. FIG. The data packets are preferably assigned according to the container type and the container ID.

In the embodiment of Figure 2, the containers 400 return their results to the container manager 100 and these are inserted by the container manager 100 into output records 220 (see the "Output Packet" in Figure 2). An output data record 220 can include the input ID and/or the status of the corresponding container. Alternatively, the container 400 can also send the output data directly to the industrial control device 300 (see the “Type 2 output packet” 225 in FIG. 1). The status mentioned above can, for example, indicate errors caused by inappropriate input data or program crashes. A status that indicates that the container is still being initialized or that indicates the computing load is also conceivable.

In both embodiments, the container manager 100 sends the output packets 220 to the appropriate return address(es) specified in the input packet 210 .

The function module 320 can then make this data available to the control logic of the industrial controller 300 so that the data is processed there.

In order to enable a particularly efficient distribution of the load, the container manager 100 container 400, in particular stateless container, on the 10 distribute the hardware available to him so that it can be used in parallel. For this purpose, the container manager 100 can identify the load of the incoming input packets 210 and start another (identical) container 400 if necessary. This distributes the load across multiple containers 400 .

The container manager 100 can also be responsible for terminating and/or removing containers 400 that are no longer required, or, if necessary, not creating new containers 400 and rejecting requests from the function modules 320, for example if the hardware is overloaded to operate more containers. In this case, the container manager 100 can take into account the policies contained in the input packets 210 .

Further functionalities for directly addressing the container manager 100 via additional function modules 320 can also be made possible, for example starting the container, updating the container, deleting and ending the container and/or an overview of the current container status.

In summary, in a preferred embodiment, the invention provides functional building blocks 320 that can be selected by the (IEC) programmer and processed with a SW/HW resource. Everything else is done by the container manager 100. The container manager 100 manages the SW/HW resources and uses the metadata stored in the function modules 320 to select which SW/HW resources are required for the functions required in the function module 320 . These SW/HW resources can be located in a cloud or in an automation network or in a normal GG cluster.

Exemplary application scenarios are explained below:

Anomaly detection: An anomaly detection algorithm can be computationally intensive and implemented in a special programming language, so that it should be operated in a container away from the industrial control. The input data could be temperatures and/or vibration in this example. This data is evaluated by the anomaly detection algorithm and the evaluation is sent to the industrial controller. Here, a function module can be used in the usual way, because ideally the container manager provides the anomaly detection in a container in the background. The function block 11 then communicates with the anomaly detection container and forwards the results to the control program.

Involvement of a third party: A container can be provided by the container manager, which directly receives the data of the function block and sends the results to it, for example a container with a low-code development environment, such as a Node-RED container.

Dashboard: A dashboard container can be provided by the container manager, which directly receives and visualizes the data of the function module. This enables an insight into the process data with little or no effort.

Claims

12 claims

1. A method in an industrial automation system, comprising:

sending an input data set (210) from an industrial control device (300) to a container manager (100), the input data set (210) comprising at least input metadata;

determining, by the container manager (100) and based on the input metadata, a runtime container (400) for processing input data;

Generating output data based on the input data by an application of the runtime container (400);

creating, by the container manager (100), an output data set (220), the output data set (220) comprising at least output metadata; and

sending the output record (220) from the container manager (100) to the industrial control device (300).

2. A method performed by a container manager (100) in an industrial automation system and comprising:

receiving an input data set (210) from an industrial control device (300), the input data set (210) comprising at least input metadata;

determining, based on the input metadata, a runtime container (400) for processing input data;

generating an output data set (220), the output data set (220) comprising at least output metadata; and

Sending the output data set (220) to the industrial control device (300). 13

3. A method performed by an industrial control device (300) in an industrial automation system, comprising:

Sending an input data set (210) to a container manager (100), the input data set (210) comprising at least input metadata, the input metadata allowing the container manager (100) to use a runtime container (400) for generating output data based on determine input data;

receiving an output record (220) from the container manager (100), the output record (220) comprising at least output metadata.

4. The method of any preceding claim, wherein the input metadata includes a container type.

5. The method according to any one of the preceding claims, wherein the input metadata comprises an input identifier, in particular a time stamp, wherein the output data set (220) comprises output metadata and wherein the output metadata has the same input identifier as the associated input - include metadata.

6. The method of any preceding claim, wherein the input metadata includes a return address.

7. The method of any preceding claim, wherein the input metadata includes a container identifier.

8. The method of any preceding claim, wherein the input metadata includes a policy.

The method of any preceding claim, wherein the output record (220) includes output metadata and the output metadata includes a status.

10. The method according to any one of the preceding claims, wherein determining a runtime container (400) for processing the input data comprises:

starting a new runtime container (400); or

Selecting an already running runtime container (400). 14

11. The method according to any one of the preceding claims, wherein the determination of a runtime container (400) for processing the input data is also based on a current utilization of processing resources for operating runtime containers (400).

12. A system or a device comprising means for carrying out a method according to any one of claims 1-11.

13. A computer program comprising instructions which, when the program is executed by a computer, cause it to carry out a method according to any one of claims 1-11.