Method and apparatus for managing automation programs of an industrial automation platform

Abstract

The invention discloses a method and an apparatus for managing automation programs of an industrial automation platform, wherein the automation programs are transferred to the automation platform and control the implementation of the automation programs on the automation platform. Herein, in a first step the automation programs or references to the automation programs are transferred by a Kubernetes master to virtual Kubelets, in a second step the transferred or referenced automation programs are transferred by a provider interface of the virtual Kubelets to the industrial automation platform, and in a third step the implementation of the transferred automation programs on the industrial automation platform is controlled, wherein control commands are transferred by the provider interface to the industrial automation platform and response messages of the industrial automation platform are received and processed or forwarded to a control entity, in particular the Kubernetes master. By this method it is possible to manage, distribute and run automation programs with the tools of a container orchestration system.

Description

Technical Field

[0001] The present invention relates to a method for managing automation programs of an industrial automation platform and an apparatus for managing automation programs of an industrial automation platform. Background Technology

[0002] Automation applications in an automation system consist of one or more automation programs running on an industrial automation platform, for example, according to the IEC 61131 standard. Such an industrial automation platform can be, for example, a Programmable Logic Controller (SPS or "PLC"). The creation and management of the automation program, such as program allocation to various controllers, program loading / starting / stopping, and program updates, are typically performed in a so-called engineering system, such as Siemens' TIA-Portal. These operations are collectively referred to as engineering and are often performed manually, resulting in low automation levels, correspondingly long changeover times, and high changeover costs. Furthermore, the engineering system must typically also be locally connected to the industrial automation platform, and the version of the engineering system must match the corresponding version and type of the application's automation platform (controller).

[0003] Below, at least the process of transferring the created automation program to the target or "target," i.e., the industrial automation platform (SPS, PLC, etc.), the initialization and stopping (start / stop) of the automation program, and the acceptance and forwarding of confirmation messages from the industrial automation platform to the control entity (e.g., HMI device; HMI = Human Machine Interface) should be collectively referred to as the "management" or "control" of the automation program.

[0004] For modular, IT-based systems—systems derived from conventional computing technologies—software container technology has been advancing for some time. Especially in distributed systems with multiple compute nodes, container-based programs distributed across these nodes are run and monitored using so-called container orchestration technologies, such as Kubernetes. In Kubernetes, this is achieved through a central component, called a host or Kubernetes host. This contains a description, or declaration, of the software components that should run. The host selects appropriate nodes and runs the containers containing the software components there; this is called a "deployment." Furthermore, the Kubernetes host monitors the components and performs recovery operations as needed, such as launching updated versions, scaling (starting / stopping mechanisms to improve / degrade performance), etc.

[0005] Essentially, for Kubernetes applications, the complete software is incorporated into one or more software containers (such as Docker containers), which are then deployed to computer hardware (often referred to as "nodes") within a runtime environment, known as a container runtime. Here, the components of a "node" are so-called Kuberneteslets, which are locally implemented software that work with the managed Kubernetes host and the local container runtime to locally download containers containing the software for implementation and monitoring.

[0006] As already mentioned, automation program management (creation, loading, starting, stopping) has traditionally been achieved manually using specialized engineering systems connected locally to industrial automation platforms (industrial controllers, SPS, PLCs, etc.). The distribution of automation programs to various automation platforms (e.g., SPS - Programmable Logic Controllers) is typically done manually.

[0007] Furthermore, the application of typical engineering systems largely depends on the organization where the engineering system exists locally within the industrial network; especially in cloud-based approaches, "remote control" requires remote workstations to have dedicated access to the local engineering system, which necessitates complex configuration of the entire system.

[0008] The publication “Kubernetes Compatible Container Orchestration on Low-Resource Edge Devices” (ISBN: 978-3-642-36741-0) by Goethals et al. demonstrates the use of virtual Kubelets for “orchestration,” that is, deploying and operating containers with software on resource-constrained devices.

[0009] The publication “Container-based architecture for flexible industrial control applications” by Goldschmidt et al. (Journal of Systems Architecture Vol. 84 (2018) pp. 28-36) discloses the simulation of proprietary PLC hardware in a container to execute proprietary control programs. Summary of the Invention

[0010] Therefore, the object of the present invention is to manage and control typical automated procedures with a high degree of automation, whereby universal, widely applicable and easily learned methods are employed as much as possible, and the dependence of the engineering system on the managed industrial automation platform is reduced, and the location dependence of the engineering system is reduced or eliminated.

[0011] In principle, the object of this invention is achieved through a known system consisting of a Kubernetes host and a Kubelet, wherein such a known system is intended for managing and controlling container-based programs in a container runtime environment. According to the invention, a virtual Kubelet is required, which behaves like a "real" Kubelet relative to the Kubernetes host, but is equipped with a specialized provider interface configured according to the invention for managing and controlling automation programs on industrial automation platforms, particularly programmable logic controllers. Virtual Kubelets are known in principle and are typically used to bring software containers to virtually every platform capable of providing a container runtime environment, particularly a cloud environment, i.e., a simulated container runtime environment in cloud service providers such as AWS (Amazon Web Services).

[0012] However, according to the present invention, a provider interface or provider plugin is provided for virtual Kubelets, which replaces container-managed automation programs, whereby the automation programs must be managed in a specialized manner and transferred to the industrial automation platform, where they are started, stopped, etc. This means that, according to the present invention, the functionality of a typical industrial engineering system, with "deployment" (software distribution) and control of the software to be implemented on the automation platform, must be provided at least by means of the provider interface. Here, virtual Kubelets designed in this way can be implemented in the field of industrial automation devices, i.e., on the correspondingly assembled programmable logic controller or the general automation platform itself, but also on a separate server, especially on industrial edge devices or edge devices. Alternatively, operation outside the industrial field can be considered, whereby the provider interface then requires data technology access to the automation platform, for example, by means of a VPN tunnel.

[0013] In particular, this objective is achieved by the method according to the invention and the apparatus according to the invention.

[0014] This document describes a method for managing automation programs on an industrial automation platform. The method involves transmitting the automation program to the platform and controlling its implementation. In a first step, the automation program or a reference for the program is transmitted from a Kubernetes host to a virtual Kubelet. In a second step, the transmitted or referenced automation program is transmitted to the industrial automation platform via the virtual Kubelet's provider interface. In a third step, the implementation of the transmitted automation program on the industrial automation platform is controlled. This involves transmitting control commands to the platform via the provider interface and receiving and processing responses from the platform, or forwarding them to control entities, particularly the Kubernetes host or operation and monitoring devices (HMI devices). This method enables the management, distribution, and execution of automation programs using a container orchestration system.

[0015] Furthermore, this objective is achieved through a device for managing automation programs on an industrial automation platform. This device includes a Kubernetes host for transmitting automation programs or references to automation programs to a virtual Kubelet; a virtual Kubelet for receiving automation programs or references to automation programs and receiving instructions for installing automation programs on the automation platform, and for controlling the operation of automation programs on the automation platform; and a provider interface for the virtual Kubelet for transmitting automation programs to the automation platform, controlling the program execution of automation programs, and receiving and forwarding response messages from the automation platform during the execution of automation programs. This device enables the realization of the advantages already described according to the method.

[0016] Preferred designs of the method according to the invention are given in various embodiments. The features and advantages described herein also apply similarly to the apparatus according to the invention. Advantageous designs can be implemented not only individually but also in meaningful combinations thereof.

[0017] While it's theoretically possible to directly create automation programs or their source code using a properly designed Kubernetes host and corresponding components, the references used for these automation programs are actually transferred through the Kubernetes host. These references can be any suitable link or "connection" to a storage location, which can then load the virtual Kubelet or its provider interface, the automation program or its source code, and specifically, the URL, storage path information, internet address, FTP address, etc.

[0018] In an advantageous design, the transmitted or referenced automation program is preprocessed before being transmitted to the automation platform. This is particularly feasible when addressing different automation platforms with different characteristics. Thus, for example, it is possible to appropriately compile automation programs for the corresponding target hardware, and it is also possible to consider that different automation platforms also address and program in different ways. In a particularly advantageous design, the provider interface enables explicit automation programs from multiple sources to be "combined," i.e., for example, linking referenced objects or libraries, compiling programs together, reloading updates to individual components, etc.

[0019] In one advantageous variant, a provider interface, or a correspondingly extended virtual Kubelet with an integrated provider interface (provider interface plugin), can configure and control the operation of different types of automation programs for multiple automation platforms. However, other advantageous variants enable the provision of various specialized provider interfaces for different types or series of automation platforms, and thus, the subsequent assembly of different virtual Kubelets or the optional integration of multiple specialized provider interface plugins into a single virtual Kubelet. This flexibility not only allows for the adoption of appropriate systems but also enables rapid and arbitrary expansion.

[0020] A dedicated provider interface, i.e., a plug-in for extending the virtual Kubelet, advantageously includes multiple functionalities corresponding to or even acquiring the functionality of a typical engineering system of an industrial automation platform. In a particularly advantageous variant, the provider interface addresses the programming interface of the actual engineering system, a so-called API (Application Programming Interface), to use its functionality (e.g., software compilation) or even to distribute and control automation programs locally within the automation network.

[0021] In a favorable variant, custom resource definitions (CRDs) are applied in Kubernetes to manage the resources of automation platforms and / or to distribute automation programs across multiple automation platforms. This allows for the identification and automatic consideration of the characteristics of automation platforms in terms of data technology, taking these characteristics into account compared to application-based container platforms.

[0022] Advantageously, it is also possible to apply so-called custom schedulers—schedules tailored to the application automation platform—to the deployment (distribution) of automation programs on their targets. Kubernetes allows for the assignment of a scheduler to each "pod," which then processes that pod. If a scheduler specific to the PLC program, tailored to the needs of the automation platform, is applied, then: firstly, the PLC program can be easily distinguished from other pods. Therefore, it is possible to associate the PLC program with the appropriate PLC node. Secondly, characteristics can be considered in the custom scheduler when scheduling the PLC program, particularly considering that automation platforms are typically populated not by "downloading" data packages in the sense of containers, but through multi-step processes.

[0023] In one implementation variant, Quality of Service (QoS) parameters are applied to assign PLC programs to appropriate PLC nodes or suitable automation platforms. Examples of QoS parameters include compute capability, latency, cycle time, availability, and privacy / security. This enables independent, automatic, and primarily reliable load distribution. Attached Figure Description

[0024] Here, Appendix Figure 1 The diagram illustrates a Kubernetes host that uses different categories of programs to set up and control three distinct nodes. Detailed Implementation

[0025] The accompanying diagram illustrates the distribution of the software across three distinct compute nodes: Node 1, Node 2, and Node 3 (nodes; nodes; target hardware, "target"). The process is controlled via a central management unit, a Kubernetes host. Within this application (labeled "Kubernetes" in the diagram), local control of the process is achieved on compute nodes Node 1, Node 2, and Node 3 (nodes; nodes), i.e., the target hardware of the program to be implemented, through agents (so-called Kubelets) present in each node.

[0026] In the accompanying diagram, a typical Kubelet is implemented locally on node 2, and its settings are used to manage software containers. Here, the Kubelet is able to implement software containers specified by instructions ("declarations") from the Kubernetes host within the local implementation environment, the "container runtime". The software containers are loaded from the specified source according to the instructions of the Kubelet.

[0027] In response, the node's Kubelet receives appropriate instructions from the host, such as through declarations or subsequent actions, to start, stop, or modify the software components running on the node. These are typically software containers (so-called nodes) or groups of software containers in Kubernetes. The interface between the Kubernetes host and the Kubelet is defined. The Kubelet has a defined interface on the node ("node") for the implementation environment ("container runtime") to enable it to start or manipulate software containers.

[0028] Kubernetes extensions introduce so-called Virtual Kubelets; these are shown in the accompanying diagrams as nodes 1 and 3. Virtual Kubelets are typically used to manage incompatible container environments (e.g., Windows containers for computers running Microsoft Windows operating systems). The principle behind Virtual Kubelets is that their interface to the Kubernetes host is designed like a regular Kubelet. Therefore, it has the same "upward" interface as a typical Kubelet, and the host communicates in the opposite direction to a typical Kubernetes node—a node capable of managing containers (or points), see the example with node 2. In principle, Virtual Kubelets can have arbitrary interfaces in the "downward" communication, i.e., with the "target." In current implementations, this is achieved through so-called providers. Typically, this provider is used either to make larger units (clusters or serverless container environments like Fargate appear as a single node) or to eliminate incompatibilities (e.g., for Microsoft Azure containers).

[0029] In the solutions for nodes 1 and 3 according to the present invention, a virtual Kubelet is used to manage the automation program or a part of the automation program. For this purpose, a dedicated PLC provider is implemented, capable of starting, stopping, monitoring, etc., the automation program on the corresponding automation platform (hereinafter referred to as "PLC runtime" in the accompanying drawings).

[0030] In the current embodiment, the specialized provider is implemented as a plug-in to the virtual Kubelet; other implementations can configure separate components for this. The plug-in, i.e., the "PLC provider" here, can be constructed in a modular manner, in particular having general components for connecting to the host-based virtual Kubelet, and on the other hand having corresponding specialized modules of a specific type for managing the automation platform.

[0031] Specifically, here, the provider plug-in PLC provider communicates with the implementation environment (the so-called PLC runtime) of the automation program of the addressed automation platform. In the case shown for node 1, the virtual Kubelet utilizes the PLC provider itself, installed on the automation platform to be managed (node ​​1). Here, the virtual Kubelet and PLC provider can be part of the firmware or installed as separate programs. Conversely, in the case given for node 3, the virtual Kubelet and PLC provider run on a separate machine, such as an industrial edge device, which not only has an industrial-grade interface for the automation platform node 3 but also an additional interface to a Kubernetes host, which can also run on a cloud provider's server.

[0032] To prepare for programming, such as in industrial engineering system projects (e.g., the ITA-Portal project), automation programs for an automation platform (PLC) are generated, mapped at "points," and stored in a referenceable source. The automation platform (PLC or virtual PLC) itself is configured and set up using network technology to enable its application. Here, a virtual PLC is a purely software-based PLC architecture implemented in a virtual machine. The functionality and logic interfaces of the virtual PLC correspond to those of an actual PLC. Then, the mapping of the basic functions of the PLC providers used to manage automation platform nodes 1 and 3 can be implemented as follows: Generate points -> Load the automation program onto an existing PLC or virtual PLC mechanism and start it. Here, the corresponding resources of the PLC / PLC mechanism are occupied and marked as occupied. Update points -> Receive changes to the automation program running on the PLC / virtual PLC mechanism. Changes can involve software status and / or configuration or implementation parameters of the automation program.

[0033] Delete the point -> stop the running automation program and release the resources occupied by the PLC / virtual PLC mechanism.

[0034] Obtain container logs -> forward to diagnostic cache or PLC diagnostic cache, involving the relevant automation program components. Get location status -> Display implementation details for the involved automation procedures, such as cycle time, storage requirements, diagnostic status, and display content. Node Conditions -> Display the extraction status of the PLC / virtual PLC mechanism (Ready, Stopped, Started, Insufficient Memory). Operating System -> Display PLC Version This mapping allows full use of existing engineering tools (such as TIA-Portal, Step7) within the PLC provider. However, the advantage of modular components is that it keeps the PLC provider lean and allows it to run on nodes with less computational power. Therefore, for example, the aforementioned basic functions can be configured as modules or plug-ins within the PLC provider. It is also possible to implement these basic functions, at least in part, by calling corresponding services in the cloud or in engineering systems running elsewhere.

[0035] Therefore, PLC providers implement working methods to load or reference PLC programs configured at startup points and transfer them to the PLC runtime. This can be achieved from the referenced source (repository) or via other sources or directories; alternatively, it can be achieved by modifying Kubernetes components (Kubernetes hosts, virtual Kubelets) to at least partially operate the PLC program itself. Additionally, the PLC provider or services addressed by it can also modify the automation program, particularly by performing platform-specific matching or compilation of the program code based on the type of PLC runtime (i.e., implementation environment or automation platform, etc.) and its current state (state, such as available storage space, firmware version, etc.).

[0036] In particular, in hybrid systems (different PLC types, a mix of PLCs and software container systems, standard computers, and container runtimes in the cloud), it is essential to be able to differentiate / identify specific runtime types. This can be achieved, for example, via tags in Kubernetes. Alternatively, the PLC provider can determine the type of the implementation environment and other parameters, and perform corresponding matching of automation programs and addressing or general data exchange with the implementation environment.

[0037] PLC providers can be integrated into automation platforms (PLCs), especially in new automation platforms, which can be easily achieved upon delivery via pre-installed firmware or as part of the firmware. This can be seen in the example of node 1, as described above. In existing systems, PLC providers can also be launched on existing computing nodes or alternatively on additional nodes to connect via a network to the automation platform / PLC and the implementation environment therein. Here, for example, it is possible to use an edge device (industrial edge device) or cloud node as the PLC provider's platform or a correspondingly designed virtual Kubelet, see node 3 in the attached diagram.

[0038] While the software distribution path described above, i.e., the "deployment" of at least one automated program at each point, allows control information, status messages, debug values, etc., to be routed from the "target" to the responsible virtual Kubelet's PLC provider on the reverse path, and then further routed, either directly or in a processed manner, to the Kubernetes host or alternative targets. Specifically, these alternative targets can be operation and monitoring devices (HMI; SCADA; MES) within or outside the automation network. Cloud-based applications are also possible. This objective can be pre-configured using a Kubernetes host; alternatively, the Kubernetes host can also forward data, either directly or in a modified form.

[0039] Therefore, this invention enables the management and operation of PLC programs using components of a container orchestration system. Furthermore, it allows for the mixed operation of PLC programs and software containers.

[0040] This enables (partially) automated allocation of PLC programs to nodes, depending on node capacity, system load, availability, etc. (i.e., generally depending on quality of service parameters). This allows for faster debugging and update times through automated "deployment" of the PLC program or parts thereof (initial installation, updates, troubleshooting, testing, etc.). Another advantage is improved availability through now possible replacement and switching methods, i.e., monitoring the PLC program and restarting on the same or other nodes. It can also now be easily integrated into CI / CD systems or DevOps, i.e., the automated chain of source code changes, compilation, testing, and debugging.

[0041] The development of a Kubernetes "ecosystem" for managing PLC programs, utilizing virtual Kubelets with provider plugins for setting up industrial automation platforms, leverages existing tools for monitoring, tracking, release policies, version control, and rollback. Therefore, PLC program management can be achieved using standard tools created from an open-source environment that provides a broad permission base and where software tools are continuously developed for further use. The advantages of software management created in a hybrid system (container-based and typically PLC-based IT) include a unified infrastructure and lower requirements for additional training of IT system professionals. Furthermore, it allows access to existing PLC systems in the field via IT mechanisms without requiring modifications to the PLC systems themselves.

Claims

1. A method for managing an automation program of a programmable logic controller, wherein, The automation program is transmitted to the programmable logic controller (PLC), and the execution of the automation program on the PLC is controlled. Its features are, In the first step, the automation program or a reference for the automation program is transferred from the Kubernetes host to the virtual Kubelet. In the second step, the automation program to be transmitted or referenced is transmitted to the programmable logic controller via the provider interface of the virtual Kubelet, and In the third step, the execution of the transmitted automation program is controlled on the programmable logic controller, wherein control instructions are transmitted to the programmable logic controller through the provider interface, and the response messages of the programmable logic controller are received, processed, or forwarded to the Kubernetes host.

2. The method according to claim 1, characterized in that, In the first step, the storage address is used as a reference for the automation program.

3. The method according to any one of the preceding claims, characterized in that, In the second step, the automation program transmitted to or designated as a reference to the virtual Kubelet is preprocessed before being transmitted to the programmable logic controller.

4. The method according to claim 3, characterized in that, In the second step, the automation program is compiled before the transmission.

5. The method according to claim 3, characterized in that, In the second step, the automation program to be transferred is a program portion transferred from the Kubernetes host and / or created from multiple referenced sources.

6. The method according to any one of claims 1-2, characterized in that, In an apparatus having multiple programmable logic controllers, a separate provider interface is applied to each individual programmable logic controller or to programmable logic controllers of the same or similar type, wherein each of the applied provider interfaces matches the automation program to be transmitted to the corresponding programmable logic controller with the type and specific attributes of the corresponding target controller.

7. The method according to any one of claims 1-2, characterized in that, The virtual Kubelet is used as the provider interface for an industrial engineering system or a portion thereof, wherein the engineering system or a portion thereof is controlled by means of instructions transmitted from the Kubernetes host to the virtual Kubelet.

8. The method according to any one of claims 1-2, characterized in that, To manage the resources of the programmable logic controller and / or to distribute the automation program to one of multiple automation platforms, a custom resource definition (CRD) is applied in the Kubernetes host.

9. The method according to any one of claims 1-2, characterized in that, A scheduler matched to the programmable logic controller is used to distribute the automation program across the programmable logic controller.

10. The method according to claim 2, characterized in that, The storage address is a URL.

11. An apparatus for managing an automation program of a programmable logic controller, the apparatus comprising: A Kubernetes host, which is used to transfer the automation program or a reference for the automation program to a virtual Kubelet; The virtual Kubelet is configured to receive the automation program or the reference for the automation program, and to receive instructions for installing the automation program on the programmable logic controller, and to control the operation of the automation program on the programmable logic controller. The provider interface of the virtual Kubelet is used to transmit the automation program to the programmable logic controller (PLC), control the program execution of the automation program, and receive and forward response messages from the PLC during the execution of the automation program.

Images