用于管理工业自动化平台的自动化程序的方法和装置与流程

1.本发明涉及一种根据权利要求1的前序部分所述的用于管理工业自动化平台的自动化程序的方法和根据权利要求10的前序部分所述的用于管理工业自动化平台的自动化程序的装置。


背景技术：

2.自动化系统中的自动化应用由一个或多个例如根据iec 61131标准的在工业自动化平台上运行的自动化程序组成。这样的工业自动化平台例如能够是可编程逻辑控制器(简写sps或“plc
”‑
programmable logic controller)。该自动化程序的创建和管理、例如程序到各个控制器的分配、程序的加载/启动/停止、程序的更新等通常在所谓的工程系统、例如西门子公司的tia-portal中进行。这些操作整体上称为工程并且在各种情况下手动控制地进行，即具有低自动化程度和相应长的改变时间和高的改变花费。此外，工程系统通常必须也本地地与工业自动化平台连接，工程系统的版本必须与应用的自动化平台(控制器)的相应的版本和类型匹配。
3.下面，至少应该将已经创建的自动化程序到目标或“靶”、即工业自动化平台(sps、plc等)的传输的过程、自动化程序的运行的初始化和停止(启动/停止)、工业自动化平台的有关自动化程序到控制实体(例如hmi装置；hmi＝人机界面)的方面的确认消息的接受和转发总体称为自动化程序的“管理”或“控制”。
4.对于模块化的基于it的系统、即来自常规的计算机技术的系统来说，软件容器技术从一段时间之前就已经实现进展。特别是在具有多个计算节点的分布式系统中，分布在计算机节点上的基于容器的程序借助于所谓的容器编排技术、例如kubernetes(https://kubernetes.io/de/)来运行和监视。在kubernetes中，其经由中央部件、所谓的主机或kubernetes主机实现。其包含应当运行的软件部件的描述、所谓的声明。主机选定合适的节点(nodes)并且在那里运行具有软件部件的容器，即被称为“部署”。此外，kubernetes主机监视部件，并且在需要时执行用于恢复的操作，例如启动更新的版本、扩展(启动/停止机构以用于提高/降低性能)等。
5.基本上对于应用kubernetes来说，完整的软件被合并到一个或多个软件容器(例如docker容器-https://www.docker.com/resources/what-container)中，其中，该容器在运行时环境、所谓的容器运行时中被传输到计算机硬件(通常被称为“节点”)上。在此，“节点”的组成部分是所谓的kuberlet，其是本地实施的软件，其与管理的kubernetes主机和本地容器运行时共同合作，以便本地下载具有软件的容器，以用于实施并且监视运行。
6.如已经提到的那样，至今为止通常尽可能手动借助于专门的工程系统实现自动化程序的管理(创建、加载、启动、停止)，该工程系统在本地与工业自动化平台(工业控制器、sps、plc等)连接。通常手动实现自动化程序到各个自动化平台的分配(例如sps-可编程逻辑控制器)。
7.此外，典型的工程系统的应用主要取决于，在本地在工业网络中存在该工程系统
的机构；尤其在基于云的方法中，“远程控制”要求远程工作站对本地工程系统的专用的访问，这要求整个系统的复杂的配置。


技术实现要素：

8.因此，本发明的目的在于，以较高的自动化程度管理和控制典型的自动化程序，在此，尽可能采用通用的、广泛的并且能容易学会的方法，并且减少工程系统对管理的工业自动化平台的依赖性，并且减少或取消工程系统的位置方面的依赖性。
9.原则上，本发明的目的通过已知的由kubernetes主机和kubelet组成的系统实现，其中，这样已知的系统考虑用于管理和控制容器运行时环境中的基于容器的程序。根据本发明，需要使用虚拟kubelet(见https://github.com/virtual-kubelet)，相对于kubernetes主机来说其行为像“真实的”kuberlet，然而配备有专门的提供者接口(见http://virtual-kubelet.io/docs/providers/#provider-interface)，其根据本发明设置用于管理和控制工业自动化平台、特别是可编程逻辑控制器的自动化程序。原则上，虚拟kubelet是已知的，并且以典型的方式用于将软件容器带到几乎每个能够提供容器运行时环境、特别是云环境、即云服务商如aws(amazon web service，亚马逊网络服务)等中的仿真的容器运行时环境的平台上。
10.然而，根据本发明，为虚拟kubelkets提供提供者接口或提供者插件，其代替容器管理自动化程序，其中，自动化程序必须以专门的类型和方式被管理并且被传输至工业自动化平台并且在那里被启动、停止等。这意味着，根据本发明，必须借助于提供者接口至少提供设置有“部署”(软件分布)和自动化平台上要实施的软件的控制的典型的工业工程系统的功能性。在此，这样设计的虚拟kubelet能够在工业自动化装置的领域中实施，即例如在相应装配的可编程逻辑控制器或一般的自动化平台自身上、然而实际上也在单独的服务器、特别是在工业边缘设备或边缘装置上。替代地，能够考虑在工业领域之外的运行，其中，然后提供者接口需要数据技术方面的对自动化平台的访问，例如借助于vpn通道。
11.特别地，该目的通过根据权利要求1所述的方法和根据权利要求10所述的装置实现。
12.在此，设置用于管理工业自动化平台的自动化程序的方法，其中，将自动化程序传输至自动化平台，并且控制自动化平台上的自动化程序的实施。在此，在第一步骤中，自动化程序或用于自动化程序的参考由kubernetes主机传输至虚拟kubelet，其中，在第二步骤中，通过虚拟kubelet的提供者接口将传输或被参考的自动化程序传输至工业自动化平台，并且其中，在第三步骤中，控制工业自动化平台上的传输的自动化程序的实施，其中，通过提供者接口，将控制指令传输至工业自动化平台并且接收和处理工业自动化平台的应答消息或者转发至控制实体、特别是kubernetes主机或操作和监视设备(hmi设备)。通过该方法能够实现以容器编排系统的方式管理、分布和运行自动化程序。
13.此外，该目的通过用于管理工业自动化平台的自动化程序的装置实现，该装置具有用于将自动化程序或用于自动化程序的参考传输至虚拟kubelet的kubernetes主机，具有用于接收自动化程序或用于自动化程序的参考和接收自动化平台上的自动化程序的安装的指令并且用于控制自动化平台上的自动化程序的运行的虚拟kubelet，并且具有用于将自动化程序传输到自动化平台、用于控制自动化程序的程序运行并且用于接收和转发在
自动化程序运行期间自动化平台的应答消息的虚拟kubelet的提供者接口。通过该装置能够实现已经根据方法阐述的优点。
14.根据本发明的方法的优选的设计方案在从属权利要求中给出。在此，描述的特征和优点类似地也适用于根据本发明的装置。有利的设计方案不仅能够单独地、还以有意义的相互组合的形式来实现。
15.尽管利用相应设计的kubernetes主机和相应设计的配合件、虚拟kubelet原则上能够实现直接已经创建自动化程序或其源代码，但实际上用于自动化程序的参考通过kubernetes主机传输。参考能够是到存储位置的每个合适的参考或“连接”，由其能够加载虚拟kubelet或者其提供者接口、自动化程序或其源代码、特别是url、存储路径信息、互联网地址、ftp地址等。
16.在一个有利的设计方案中，传输的或被参考的自动化程序在传输到自动化平台之前被预处理。这尤其能够实现地是，寻址具有不用的特性的不同的自动化平台。从而例如能够合适地为相应的目标硬件编译自动化程序并且能够考虑的是，不同的自动化平台也以不同的类型寻址和编程。特别地在一个有利的设计方案中，提供者接口使得来自多个源的明确的自动化程序“组合在一起”，即例如连接参考的对象或库，一起编译程序、重新加载各个元件的更新等。
17.在一个有利的变体方案中，提供者接口或具有集成的提供者接口(提供者接口插件)的相应扩展的虚拟kubelet能够为多个自动化平台设置不同类型的自动化程序并且控制其运行。然而，在其它有利的变体方案中能够实现的是，为不同的类型或类型系列的自动化平台提供各种专门的提供者接口，并且因此，随后也装配不同的虚拟kubelet或者可选地集成多个各种专门的提供者接口插件到整体地虚拟kubelet中。通过该灵活性不仅已经能采用相应地系统，还能快速任意地扩展。
18.专门的提供者接口、即用于扩展虚拟kubelet的插件有利地包含多个功能，其对应工业自动化平台的典型的工程系统的功能或者甚至获取其。在一个特别有利的变体方案中，提供者接口寻址实际存在的工程系统的编程接口、所谓的api(application programming interface，应用编程接口)，以便使用其功能性(例如软件的编译)或者甚至分布和控制在本地在自动化网络中的自动化程序。
19.在一个有利的变体方案中，为了管理自动化平台的资源和/或为了将自动化程序分配给多个自动化平台而在kubernetes中应用自定义资源定义(custom resource definition(crd))(见：https://kubernetes.io/docs/concepts/extend-kubernetes/apiextension/custom-res ources/)。因此，能够在数据技术方面确定并且自动考虑自动化平台的特点，与应用基于容器的平台相比，要注意这些特点。
20.有利地，也能够实现的是，为自动化程序在其目标上的部署(分布)应用所谓的自定义调度程序(见：https://kubernetes.io/docs/concepts/scheduling/kubescheduler)，即对于应用自动化平台来说匹配的调度程序。利用kubernetes能够在每个“点位(pod)”给定调度程序，利用调度程序处理该点位。如果对为plc程序应用特有的、即专门匹配自动化平台的需求的调度程序，那么能够实现：一方面，plc程序能够容易与其它的点位区分。因此，能够实现plc程序与合适的plc节点的关联。另一方面，能够在调度plc程序时在自定义调度程序中考虑特点，特别能够考虑的是，自动化平台通常不通过“下载”数
据包在容器的意义上，而是在多步骤的流程中被填充。
21.在一个实施变体方案中，应用服务质量参数(qos参数)，以便将plc程序分配给合适的plc节点或者合适的自动化平台。qos参数的实例是计算能力、延迟时间、周期时间、可用性、隐私/安全等。因此能够实现独立、即自动并且首先功能可靠的负载分布。
附图说明
22.在此，唯一的附图示出了kubernetes主机的示意图，其利用不同分类的程序设置和控制三个不同的节点。
具体实施方式
23.附图示出了软件在三个不同的计算节点结点1、结点2、结点3(节点；结点；目标硬件，“靶”)上的分布。该过程通过中央管理装置、kubernetes主机来控制。在该应用(在附图中以“kubernetes”标记)中，通过在每个节点中存在的代理(所谓的kubelet)实现该过程在计算节点结点1、结点2、结点3(节点；结点)、即要实施的程序的目标硬件上的本地的控制。
24.在附图中，在本地在节点结点2上实施典型的kubelet，其设置用于管理软件容器。在此，kubelet能够在本地实施环境“容器运行时”中实施借助于kubernetes主机的指令(“声明”)说明的软件容器。软件容器根据kubelet的指示从说明的源中加载。
25.对此，节点的kubelet从主机得到相应的指示，例如利用声明或之后，以用于启动、停止、改变在节点上运行的软件部件。其通常在kubernetes中是软件容器(所谓的点位)或软件容器组。kubernetes主机和kubelet之间的接口是确定的。kubelet在节点(“结点”)上具有限定的用于实施环境(“容器运行时”)的接口，以便能够启动或操纵软件容器。
26.kubernetes的扩展引入了所谓的虚拟kubelet；其在附图中根据节点结点1、结点3示出。虚拟kubelet以典型的方式用于管理不兼容的容器环境(例如用于具有微软windows操作系统的计算机的windows容器)。虚拟kubelet的原理是，其到kunernetes主机的接口像常规的kubelet那样被设计。因此，其具有“向上”的与典型的kubelet一样的接口，并且主机如与典型的kunernetes结点以相反的方向通信，即能够管理容器(或点位)的节点，见具有节点结点2的实例。向“下”、即在与“靶”的通信中，虚拟kubelet原则上能够具有任意的接口。在当前的实施中(https://github.com/virtual-kubeletvirtual kubelet/)，这通过所谓的提供者实现。以典型的方式，该提供者要么用于使较大的单元(簇或无服务器容器环境如fargate)显示为单个节点，要么用于消除不兼容性(例如用于微软azure容器)。
27.在所示的根据本发明的节点结点1、结点3的解决方案中，应用用于管理自动化程序或自动化程序的一部分的虚拟kubelet。对此，实施专门的plc提供者，其能够将相应的自动化平台(接下来和在附图中称为“plc运行时”)上的自动化程序启动、停止、监视等。提供者必须满足的基础功能在https://github.com/virtual-kubelet/virtual-kubelet中描述。
28.在当前的实施例中，该专门的提供者分别作为虚拟kubelet的插件实现；其它的实施能够对此设置单独的部件。插件、即在此的“plc提供者”能够自身是以模块化的方式构件的，特别是具有用于连接到主机化的虚拟kubelet的通用部件，另一方面具有用于管理自动化平台的相应的专门的类型的专门的模块。
29.在此，具体地，提供者插件plc提供者与寻址的自动化平台的自动化程序的实施环境(所谓的plc运行时)通信。在此，根据节点结点1示出的情况为，在其中，虚拟kubelet利用plc提供者自己安装在要管理的自动化平台(结点1)上。在此，虚拟kubelet和plc提供者能够是固件的组成部分或者作为单独的程序被安装。相反地，根据节点结点3给出的情况为，在其中，虚拟kubelet和plc提供者在单独的机器上运行，例如在工业边缘设备上，其不仅具有用于带有自动化平台结点3的工业等级的接口，还具有到kubernetes主机的另外的接口，其中，后者也能够在云提供者的服务器上运行。
30.为了准备编程，例如在工业工程系统的项目(例如ita-portal项目)中产生、在“点位”上映射并且在能被参考的源中存储用于自动化平台(plc)的自动化程序。自动化平台(plc或虚拟plc)自身被配置并且在网络技术上被设置，使得其能够被应用。在此，虚拟plc是纯基于软件的plc机构，其在虚拟机中实施。虚拟plc的功能性和逻辑接口对应实际的plc。然后，用于管理自动化平台结点1、结点3的plc提供者的基础功能的映射能够如下实现：
31.·
生成点位-》将自动化程序加载到现有的plc或虚拟plc机构上并且将其启动。在此，占据plc/plc机构的相应的资源并且标记为已占据
32.·
更新点位-》接收plc/虚拟plc机构上运行的自动化程序的改变。改变能够涉及软件状态和/或自动化程序的配置或实施参数。
33.·
删除点位-》停止运行的自动化程序，并且释放plc/虚拟plc机构上占据的资源。
34.·
获取容器日志-》转发诊断缓存或者plc的诊断缓存的涉及相应的自动化程序的部分
35.·
获取点位状态-》显示用于涉及的自动化程序的实施细节、例如周期时间、存储需求、诊断状态、显示内容
36.·
节点条件-》显示plc/虚拟plc机构的提取的状态(准备、停止、启动、内存不足)
37.·
操作系统-》显示plc版本
38.在该映射中能够完全在plc提供者中使用存在的工程工具(例如tia-portal、step7)。然而，模块化的部件的优点在于，使得plc提供者保持纤细，并且也能够在节点上以较小的计算能力运行。因此例如能够设置之前所述的基础功能作为plc提供者中的模块或插件。也能够实现的是，该基础功能至少部分地通过调用云或在其它地方运行的工程系统中的相应的服务来实现。
39.因此，plc提供者实施工作方法，以便在启动点位时能够加载对此设置的或参考的plc程序并且传输到plc运行时。这能够由被参考的源(存放库)或者经由其它的源或目录实现；替代地，能够实现的是，kubernetes部件(kubernetes主机、虚拟kubelet)改变为，至少部分地操作plc程序自身。附加地，能够由plc提供者或由其寻址的服务也进行自动化程序的改变，特别是根据程序代码根据plc运行时(即实施环境或自动化平台等)的类型和当时的状态(状态，例如空余的存储空间、固件版本等)、对程序代码进行的平台特定的匹配或编译。
40.特别地，在混合系统(不同plc类型、plc与软件容器系统混合、标准计算机、云中的容器运行时)中，必须能够实现运行时的特殊的类型的区别/识别。这例如经由kubernetes中的标签实现。也能够实现的是，plc提供者自己得出实施环境的类型和其它的参数，并且
进行自动化程序和寻址或与实施环境的一般的数据交换的相应的匹配。
41.plc提供者能够集成到自动化平台(plc)中，这尤其在新的自动化平台中已经在供货时能够通过预安装固件或作为固件的组成部分被容易地实现。如上所述，这能够在结点1的实例中看到。在现有的系统中，plc提供者也能够在现有的计算节点上或替代地在附加的节点上启动，以便经由网络与自动化平台/plc和在那里的实施环境连接。在此，例如能够实现的是，边缘装置(工业边缘设备)或云节点用作为plc提供者的平台或者相应设计的虚拟kubelet，见附图中的结点3。
42.在上述描述软件分布的路径、即点位利用至少一个自动化程序的“部署”的同时，能够在反向路径上将控制信息、状态消息、调试值等从“靶”引导至负责的虚拟kubelet的plc提供者，并且在那里以或者经处理的方式进一步引导至kubernetes主机或可替换的目标。特别地，这些可替换的目标能够是自动化网络之中或之外的操作和监视设备(hmi；scada；mes)。也能够实现基于云的应用。该目的能够借助于kubernetes主机来预设；替代地，kubernetes主机也能够将数据或者也以经改变的形式转发。
43.因此，借助于本发明能够利用容器编排系统的构件来管理和运行plc程序。在此，也能够实现plc程序与软件容器的混合运行。
44.由此，能够实现plc程序取决于节点容量、系统负载、可用性等(即一般取决于服务质量参数)到节点的(部分)自动化的分配。这能够通过plc程序或plc程序部分的自动“部署”(初次安装、更新、排错、测试等)实现更快的调试和更新时间。另一个优点在于，通过现在可能的替换切换方法、即监视plc程序、在相同或其它节点上重启提高可用性。现在也能够简单地连接到ci/cd系统或devops中，即源代码改变、编译、测试、调试自动化链。
45.使用具有设置用于工业自动化平台的提供者插件的虚拟kubelet的开发了用于管理plc程序的kubernetes“生态系统”，例如利用现有工具进行监视、跟踪、发行策略、版本控制、撤回。因此，plc程序的管理能够利用来自开源环境创建的标准工具来实现，开源环境给出广泛的权限基础，并且其中，持续进一步开发使用的软件工具。混合系统(基于容器和典型地plc的it)中创建的软件管理的优点在于，统一的基础架构和对it系统专业人员的附加的培训的较小的要求。此外，能够利用it机制访问现场的现有plc系统，而无需改变plc系统。