CN115268978A - 用于有状态应用的灵活更新机制 - Google Patents

Abstract

本公开的各实施例涉及用于有状态应用的灵活更新机制。提供了一种计算机实现的更新管理方法，用于管理应用的应用状态从源节点到分布式控制系统的至少一个目标节点的传递。该方法包括：标识应用状态的第一部分，第一部分能够独立于应用状态的第二部分被传递；确定在应用的一个执行周期期间第一部分能够从源节点被传递到至少一个目标节点；通过在应用的第一执行周期期间将应用状态的第一部分从源节点传递到至少一个目标节点来执行第一部分更新；以及通过在应用后续的第二执行周期期间将应用状态的第二部分从源节点传递到至少一个目标节点来执行第二部分更新。

Description

用于有状态应用的灵活更新机制

技术领域

本发明涉及用于管理应用的应用状态从源节点到分布式控制系统的至少一个目标节点的传递的系统和方法。

背景技术

在工业过程控制系统中，控制应用被执行以基于传感器数据计算致动器的输出。应用需要被灵活部署以：1)在以网络为中心的控制系统架构中优化工作负载/CPU负载/存储器负载；2)更新控制应用和执行引擎；3)测试控制应用/执行引擎中的改变。停止应用以进行更新是不期望的，以避免中断基础生产过程，尤其是在对控制代码进行较小调整的情况下。如果无法保证更新期间的周期时间，则停止不可避免。因此，满足周期时间是硬性要求。此外，如果应用实例在不同节点上执行，则必须经由网络传递状态，这会在状态传递过程中引入附加延迟。结果，可能无法满足应用的周期时间。

发明内容

因此，有状态应用需要更灵活的更新机制。独立权利要求的主题满足了这种需要。从属权利要求阐述了可选特征。

根据第一方面，提供了一种计算机实现的更新管理方法，用于管理应用的应用状态从源节点到分布式控制系统的至少一个目标节点的传递。方法包括：标识应用状态的第一部分，第一部分可以独立于应用状态的第二部分被传递；确定在应用的一个执行周期期间第一部分能够从源节点被传递到至少一个目标节点；通过在应用的第一执行周期期间将应用状态的第一部分从源节点传递到至少一个目标节点来执行第一部分更新；以及通过在应用后续的第二执行周期期间将应用状态的第二部分从源节点传递到至少一个目标节点来执行第二部分更新。

根据本公开，应用可以被拆分，以创建能够彼此独立操作的多个解耦的部分。以这种方式，本发明提供了应用的缩放，以使其能够在分离的节点上运行，能够在节点边界上进行更新，以及能够提供更灵活的应用部署。应用的每个部分可以与应用的应用状态的对应部分相关联。因此，应用状态的可以独立于应用状态的其余部分更新的至少一部分，可以基于其与应用的所述解耦的部分的对应关系来被标识。方法可以包括拆分应用以创建解耦的部分。拆分应用可以包括：分析与应用相关的工程数据以标识可以解耦的部分。工程数据可以包括应用的控制逻辑和/或其程序代码(尤其是应用的结构化控制代码)的图形表示和/或叙述性表示。标识可以解耦的应用部分可以包括：标识控制逻辑和/或代码的在某个预先确定程度上彼此独立的部分，即，耦合的强度或部分之间的相互依赖程度满足预先确定标准。可以使用静态分析(例如静态代码分析)来标识可以解耦的应用部分。标识可以解耦的应用部分可以包括标识全局变量和/或局部变量，后者是分布式控制系统的不同子系统使用的变量。拆分应用可以包括使用局部变量来标识拆分点。在无法实现完全解耦的情况下，拆分应用可以包括使用附加变量来表示控制逻辑的全局变量。方法可以包括：确定由附加变量的使用产生的附加负载。附加负载可以包括在一个或多个目标节点处的附加网络负载和/或附加计算负载。方法可以包括：响应于附加负载未能满足预先确定标准(例如阈值，超过该阈值，附加负载被认为是不利的)而提供警报。该警报可以用于避免拆分应用，和/或延迟拆分应用，和/或建议不拆分应用。方法可以包括确定当前网络状况，例如当前网络负载和/或网络吞吐量。方法可以包括：基于附加网络负载和/或所确定的当前网络状况，来确定应用是否可以保持操作。确定应用是否可以保持操作可以包括：计算用于传递附加网络负载的剩余松弛时间。方法可以包括：响应于检测的网络负载超过特定阈值，延迟传递或推荐延迟传递。方法还可以包括将由应用的拆分导致的改变写回到工程数据，例如，写回改变的控制逻辑。

方法可以包括将解耦的部分部署到至少一个目标节点。解耦的部分可以与在源节点上执行的源应用(即原始应用)并行执行。解耦的部分可以以使得：给定解耦的部分被部署到仅一个相应目标节点，给定解耦的部分被部署到一个以上目标节点，或者多个解耦的部分被部署到单个目标节点的方式，而被部署到目标节点。解耦的部分和目标节点之间的关联在本文被称为部署方案。方法可以包括确定部署方案。确定部署方案可以包括选择解耦的部分将被部署到的目标节点。可以基于目标节点处的可用计算资源(例如，处理器或存储器资源，即CPU或RAM)进行选择，例如以实现节点中间的负载平衡，以最小化网络流量(的任何增加)，或控制应用大小(例如以便于维护)。

通过确定在应用的一个执行周期期间，至少一个部分能够在传递任何其他独立部分之前从源节点被传递到至少一个目标节点，本发明能够保证应用的周期时间可以被满足，虽然整体传递可能需要更长时间。该确定可以包括：计算在一个执行周期内可以经由将源节点连接到至少一个目标节点的网络传递的最大数据量。计算最大数据量可以包括：获得与网络中的条件有关的数据，条件包括例如网络容量、负载、延时、带宽等中的一个或多个；以及基于该数据执行计算。该确定可以包括：获得定义要被传递的至少一个部分的大小的数据。该确定可以包括计算该大小。大小可以包括至少一个部分中的每一个变量的大小和/或数目，或者至少一个部分中的变量(在源节点上运行的应用与在至少一个目标节点上运行的应用的至少一个部分之间的差异与该变量相关地被标识)的大小和/或数目。方法可以包括：基于从源节点和目标节点检索或读出的应用状态来标识那些差异。该确定可以包括：确定应用的一个以上所述部分可以在一个执行周期期间被并行传递。可以基于在一个周期内可以传递的最大数据量和多个部分的大小来做出该确定。因此，方法可以包括：标识应用状态的部分的批量，该部分的批量要从源节点被并行传递到一个或多个目标节点。计算最大数据量可以包括：考虑计算时间，以便确定松弛时间，传递将在松弛时间期间被实施。计算时间可以包括源应用和/或更新管理器执行计算(其输出与传递相关)所花费的时间。

方法可以包括在相应的连续执行周期期间个体地传递应用状态的部分，和/或在单个执行周期期间并行地传递多个部分。并行传递的多个状态部分可以被称为批量或块。在一个执行周期期间并行传递多个部分的动作可以被称为批量传递。传递可以涉及在一个周期期间传递应用状态部分的第一批量，在另一个周期期间传递部分的第二批量，等等。单个部分或部分的批量在相应执行周期期间的传递可以被迭代执行，直到应用的所有部分已经被传递为止，或者至少直到那些部分的预先确定子集(例如，在目标节点处产生可接受的结果所需的预先确定最小子集)已经被传递为止。执行传递可以包括发布资源预留，以预留例如执行传递所需的网络和/或计算资源。

方法可以包括验证传递。可以根据预先确定标准自动验证传递，或通过输出信息以由工程师批准来手动验证。验证传递可以包括：将应用的一个或多个部署的部分产生的输出与源应用产生的对应输出进行比较。如果这些输出之间存在差异(在本文被称为delta)，则可以根据预先确定标准(诸如，绝对值或相对值的阈值或相似性指标等)自动接受该delta，或通过输出delta以由工程师接受来手动接受该delta。如果针对应用的特定部署的部分的delta不被接受，则可以重复该部分的传递。如果delta被接受，则到该部分的切换可以被执行。以这种方式，可以确保所传递的应用部分不会以不可接受的错误状态运行。

执行到应用的特定部分的切换可以包括：使用该部分的输出信号来控制工业过程。执行切换还可以包括：禁用或忽略源应用的对应输出信号。在所有必要的应用部分已经被传递之后，执行切换可以包括删除或卸载源应用。

因此，本公开提供了一种在线更新机制，以用于控制在不同物理节点上的容器化环境中运行的应用，从而允许对应用进行部分更新和/或将应用拆分到不同的节点上。根据本公开，即使在一个周期时间内不可能进行完全传递，也可以通过接受所拆分和部署的应用的输入/输出信号中的给定delta来执行状态传递。本公开提供了应用的自动缩放，以使它们更小以便让它们在分离的节点上运行，从而使得能够在物理节点边界上更新应用和更灵活地部署应用。考虑到不同的要求(如CPU或RAM意义上的负载平衡、网络流量或控制应用大小(以更轻松地维护应用等))，可以提供控制应用到不同节点的优化部署(例如，1对n)。

如本文所指的“应用”特别可以是有状态的、容器化的应用，并且还可以被称为控制(逻辑)应用或过程自动化应用。

“传递”在本文意指一个应用的状态或该状态的一部分被另一应用的状态或该另一应用的状态的一部分覆盖。

本文使用的“更新”是指覆盖状态的该过程。

“部署”意指应用或应用的一部分被安装以在节点的执行引擎上运行，或者意指节点被指示以实现该应用或部分的控制逻辑。“被部署”在本文中用于指代如此部署的应用或应用的一部分，但尤其指代在相应目标节点上与源应用在源节点上的执行并行执行的拆分源应用的那些部分。

根据第二方面，提供了一种计算设备，其包括被配置为执行第一方面的方法的处理器。

根据第三方面，提供了一种计算机程序产品，其包括指令，该指令在由计算设备执行时，使能或使得计算设备执行第一方面的方法。

根据第四方面，提供了一种计算机可读介质，其包括指令，该指令在由计算设备执行时，使能或使得计算设备执行第一方面的方法。

本发明可以包括单独或组合的一个或多个方面、示例或特征，无论是否以这种组合或单独的方式被具体公开。上述方面之一的任何可选特征或子方面适用于任何其他方面。

本发明的这些和其他方面将从下文描述的实施例变得明显并且参考下文描述的实施例来阐明。

附图说明

现在将参考附图，以示例的方式给出详细描述，其中：

图1图示了容器化环境，其中更新管理器管理对控制应用的更新；

图2是表示由图1的更新管理器执行的更新管理方法的流程图；

图3A至图3G图示了图2的方法的各个阶段；以及

图4图示了可以根据本文公开的系统和方法使用的计算设备。

具体实施方式

图1示出了包括分布式控制节点106-1的分布式控制系统(DCS)100，该分布式控制节点106-1在其执行引擎112-1上运行有状态应用108-1(即具有状态110-2的应用)。

应用108-1是实现控制算法的程序，用于控制一个或多个现场设备114来调节工业过程。现场设备114可以包括一个或多个传感器和/或致动器，用于控制例如油管中的温度和流量、化学反应器的填充水平，或(作为PID控制器)控制锅炉中的气体流量。现场设备114经由网络116连接到DCS 100的节点106。传感器周期性地将更新值(例如，温度为70度)作为输入信号发送到应用108-1，而致动器持续监听来自该应用108-1的输出信号(例如，将阀门关闭至20％)。

例如，可以使用五种IEC 61131-3编程语言(结构化文本、功能框图、指令列表、顺序功能图、梯形逻辑)之一来实现应用108-1。在执行期间，应用状态110-1可以包括变量的值(例如计数器变量的值)、中间计算、计时器、过去的执行、功能框内部状态等。对于过程自动化应用，通常可以存在数千个变量，构成应用状态110-1，因此应用状态110-1可以消耗大量存储器。应用108-1可以由自动化工程师使用诸如ABB CBM的应用工程工具118来实现。

执行引擎112-1提供能够周期执行应用108-1(例如，根据IEC61131-3)的运行时环境。运行时周期性地接收来自相应现场设备114的输入信号(例如，每1ms至100ms一次)，对输入信号执行对应的控制算法，从而生成输出信号，并且使用相同的周期时间将输出信号发送到该现场设备114。对于执行应用108-1，可能需要将该计算的快速周期时间降至1ms至10ms。

可能需要将应用108-1部署到另一个节点。例如，可以执行这种部署以优化工作负载(例如CPU负载、存储器负载)跨节点的分布，更新应用或执行引擎，或测试应用或执行引擎中的改变。如本领域已知的，可以采取L-E-G(加载评估和执行)过程，其中在目标节点106-x的执行引擎112-x上与源应用108-1并行运行另外的应用108-x(在本文中可以被称为部署或更新的应用)。两个应用的输入和输出(I/O)被比较。如果比较的结果可接受，则到部署应用108-x的切换被触发。为了更新部署应用108-x的状态110-x，在网络116上传递源应用108-1的状态110-1(或该状态的预定义最小集合，以便它能够产生相同结果，或者在逻辑改变情况下故意产生不同结果)。对这种传递的需求产生了由于网络延迟而不能满足应用108的周期时间的可能性。

本文公开了系统和方法，用于以减轻网络延迟对满足应用周期时间的能力的影响的方式，来更新在分布式控制系统的不同分布式控制节点上执行的应用。

特别地，图1还图示了更新管理器102，更新管理器102管理对应用的更新。在本示例中，在被称为L-E-G管理节点104的不同节点上的软件容器中实现更新管理器102。更新管理器102可以提供用户接口，以用于与工程师120或其他用户交互，例如以显示信息和接收用户命令。更新管理器102被配置为执行更新管理方法。

图2图示了更新管理方法200。

在步骤201中，启动更新过程200，以灵活地将应用108-1的状态110-1传递到一个或多个目标节点。可以由工程师120利用更新请求调用更新管理器102，来手动启动更新过程200。更新请求可以是非特定更新请求(即不标识任何目标节点的更新请求)，或者是特定更新请求(其中指定了用于更新的一个或多个目标节点)。当部署方案未知时，可以使用非特定更新请求。当部署方案已经被确定时，可以使用特定更新请求。

在步骤202中，更新管理器102确定部署方案是否已经由工程师120提供和实施。如果是，则方法进行到步骤204。如果否，则更新管理器102在步骤203中确定部署方案。

在步骤203中，为了确定部署方案，更新管理器102可以被配置为获取与应用108-1相关的工程数据，并且使用工程数据来确定是否可以将应用108-1拆分为多个解耦的部分以用于部署到多个目标节点。例如，应用的解耦的部分可以是任务、程序组织单元(POU)或输入/输出信号和/或功能框的任何组合，该解耦的部分不具有外部依赖关系(例如，与其他信号或通信变量)，或者只具有最小的依赖关系。例如，更新管理器102被配置为获得应用108-1的静态表示，静态表示例如是表示应用的结构化文本或功能框图。更新管理器102能够通过访问应用工程工具118来获得控制程序的该静态表示(如果它不能以其他方式获得)。更新管理器102基于控制程序的静态表示，来计算控制程序中的潜在拆分点。例如对于结构化文本，例如对于61131控制逻辑，可以通过使用静态代码分析方法来计算拆分点，以标识由不同子系统使用的全局变量，即由控制代码的一部分写入并且由另一部分读取的全局变量。然后，这些部分可以表示要被拆分开的候选。可以在控制程序中明确指定全局变量。这些变量可以是I/O变量。在PLC程序中，全局变量是子系统之间通信的关键机制。因此，通过分析对全局变量的访问，可以确定子系统之间耦合的强度。该信息可以用于显示控制逻辑中的潜在拆分点，以便将应用拆分为解耦或隔离的部分。当拆分部分被部署到不同节点时，拆分过程可能需要(在部署之后)使用附加的通信变量-来表示控制逻辑程序的全局变量。执行静态代码分析可以包括使用依赖关系图，来确定源应用108-1的不同部分如何相互交互。可以在该图中检测孤立集群，孤立集群彼此没有依赖关系，或者最大为例如一个依赖关系，然后可以通过使用附加的通信变量来实现该一个依赖关系。用于拆分应用的另外的技术对于本领域技术人员将是明显的。

在拆分应用之后，更新管理器102被配置为：基于应用拆分的结果以及也可选地基于确定的资源限制(诸如潜在目标节点处的计算资源限制或网络资源限制)，生成一个或多个不同的候选部署方案，候选部署方案指示在何处部署应用的哪个部分(其中部署方案被选择例如以最小化网络流量)。为此，更新管理器102可以被配置为使用例如标准基准应用数据来确定目标节点计算资源限制。例如，在目标节点处，计算资源限制可以包括CPU利用率、存储器(例如，RAM)可用性、抖动、平均周期时间、执行优先级等中的一个或多个。网络资源限制可以以下面描述的方式被确定。根据本公开，源应用108-1可以使用1对1部署方案(其中应用从一个节点被部署到另一个节点(具有可选的拆分))或1对n部署(其中应用被拆分并且从一个节点被部署到多个节点，即n个目标节点)来被部署。

剩下图2的步骤203，所生成的候选部署方案作为选项被输出给工程师120来选择或确认。到工程师120的输出可以指示应用的哪些部分(例如，控制逻辑的哪些部分和/或应用状态的哪些变量或其他部分)将被传递到给定候选部署方案的哪些节点。在方案被选择之后，接收节点(即，目标节点，或者更特别地它们的接收执行引擎)可以手动或自动地为部署做好准备，并且应用的部分被部署，即被上传到接收节点。上传的部分然后与源应用108-1并行执行。

为了避免信息丢失并且不使重构、维护或故障排除复杂化，由拆分产生的改变的控制逻辑可以被存储在更新管理器102中和/或被记录在工程工具118中。还可以存储关于应用的哪个部分在哪个节点上运行的指示。如果使用1对1部署方案，则对工程工具118的唯一更新可以包括关于哪个节点正在执行部署的应用的指示。当实现从1个节点到n个节点的部署时，更新管理器102可以提供到工程工具118的链接，以将控制逻辑中的改变写回到原始工程项目。该写回可以由工程师120批准。可以在ST(61131)代码级别下执行写回过程。工程工具118可以向工程师120提供逻辑视图和另一视图和视图之间的简单切换，逻辑视图描绘信号的连接(好像它将在单个节点中执行)，该另一视图显示设备上的代码的分配(例如，如今天在CBM中完成的那样)。

由于需要在源应用108-1的不同拆分部分之间交换信息，通过拆分源应用108-1将应用108-1部署到不同节点106可能导致增加的网络负载。例如，以前用于在应用的部分之间通信、现在由上述附加通信变量表示的全局变量，可能产生要经由网络116通信的附加信号。例如，一个拆分部分(现在在第一目标节点上执行)的输出可以成为另一个拆分部分(现在在第二目标节点上执行)的输入。这种附加信号可以在网络内发布，并且应用的其他拆分部分(现在在不同节点上运行)可以订阅它们，遵循Pub/Sub概念。更新管理器102可以被配置为确定由于拆分应用导致的网络负载的增加，例如基于从源应用的哪个拆分部分写入哪些变量以及从应用的其他拆分部分读取哪些变量。例如，更新管理器102可以根据要传输的数据的类型和大小，来计算需要创建多少新订阅以及将引起多少新流量。

更新管理器102还可以被配置为确定当前网络状况。例如，更新管理器102可以被配置为检测当前网络负载。附加地或备选地，更新管理器102可以被配置为计算网络吞吐量。吞吐量表示能够经由网络116从一个节点传输到另一个节点的最大数据。更新管理器102可以被配置为将网络吞吐量计算为：吞吐量＝批量大小/延时。更新管理器102可以被配置为基于DCS 100正在使用的网络协议来确定批量大小。例如，在使用基于UDP的协议OPCUA(它使用IP协议作为底层基础)的情况下，可以根据传输控制协议窗口TCP窗口将批量大小确定为＝65535字节x8＝524288位。更新管理器102可以被配置为通过向一个或多个其他节点106发送ping来测量网络的延时。假设在OPC UA示例中延时为2ms，吞吐量可以被计算为524288/0.002/1000000＝26214Mbps。

更新管理器102可以被配置为执行决策算法，该算法将由拆分应用产生的确定附加网络负载和/或所确定的当前网络状况作为输入，并且应用一个或多个预先确定规则来确定传递是否可行，和/或决定后续行动过程，以便避免在网络上发布具有负面影响的更多信号。

例如，如果附加网络负载和网络状况使得附加信号在网络116上的传递不能足够快地被执行以确保应用仍然可操作，则更新管理器102可以推荐或实施返回到应用拆分步骤，以便部署方案可以被改变。备选地，更新管理器102可以建议不拆分应用。

为了确定应用是否可以保持可操作，更新管理器102可以被配置为：在从应用的周期时间扣除完成一个或多个预先确定的其他与传递相关任务的预期时间之后，确定用于传递附加网络负载剩余的松弛时间。继续以OPC UA为例，80ms的周期时间将提供每80ms20.97Mb的网络吞吐量。这表示理想化的场景，因为整个周期时间不能花费在传递附加网络负载上。因此，更新管理器102可以被配置为从周期时间扣除完成一个或多个预先确定的其他传递相关任务的预期时间，诸如从源引擎112-1检索存储器状态并且将其序列化(例如，20ms)，将该数据解序列化并且将其写入目标引擎(例如15ms)，创建到源引擎和目标引擎的连接(例如每个连接6ms)，等等。剩余的松弛时间可用于传递附加网络负载。在OPC UA示例中，剩余33ms来传递附加网络负载，这有足够的时间来传递8.6Mb。

在应用预先确定规则的另外示例中，更新管理器102可以被配置为：响应于检测的网络负载超过特定阈值(例如，其容量的70％)而延迟传递或推荐延迟传递。

如果决策算法的输出是传递可行，则方法进行到步骤204。

在图2的步骤204中，方法然后继续更新应用的部署的部分，使得每个状态部分与源应用108-1的状态110-1的对应部分的状态部分匹配，或者包括由例如工程师120故意引入的、从源应用108-1的预先确定偏差。为了开始更新过程，更新管理器计算目标节点106上可以被并行更新的执行引擎112的数目m。该数目在本文中可以被称为批量大小，并且要传递的m个状态部分可以被统称为批量或块。

为此，更新管理器102计算要在网络116上传递的每个状态部分的大小。该大小可以以例如kB来计算，或可以从要更新的变量的数目导出或表示。要更新的变量可以包括由要更新的特定应用部分使用的变量的全部或预先确定子集。备选地，相应应用部分和源应用108-1的对应部分之间的输出的不匹配与其相关的仅那些变量可以被更新，例如通过比较发送和接收执行引擎112中的每个引擎中的状态110的当前值来检测该不匹配。换句话说，更新管理器102可以被配置为：通过检测在目标节点106上运行的应用部分的状态与源应用108-1的状态110-1相比的差异，来标识要传递的变量。在这点上，更新管理器102被配置为例如通过读出应用的状态来获得它们。特别地，更新管理器102被配置为确定源应用108-1的状态110-1以及在接收执行引擎上运行的每个应用部分的状态两者。

更新管理器102还被配置为确定可用网络容量。例如，更新管理器102可以被配置为确定网络112的延时和/或带宽(例如，最大3ms延时，1Gbps的83％可用)，例如基于发送到节点106中的一个或多个节点的ping来计算。

更新管理器102还被配置为确定源应用108-1的周期时间。这可以是已知的或者可以由更新管理器102测量。

基于要传递的状态部分的大小和可用的网络容量，更新管理器102计算在一个执行周期期间可以并行更新多少个执行引擎112，以便可以满足应用的周期时间。可能的情况是整个更新过程可以在一个执行周期内完成。然而，对于具有短周期时间的应用，更新过程更有可能将需要多个执行周期才能完成，其中在每个执行周期期间传递一个应用状态部分或一批应用状态部分。鉴于与源应用的隔离部分相关的状态部分，关于在下一个执行周期期间要传递哪些状态部分以及要更新的应用部分的其他状态部分的选择是非关键的。

为了提供能够满足周期时间的进一步保证，更新管理器102可以被配置为：确定松弛时间(即，在处理任务之后剩余的执行周期的那部分)，并且在计算在下一个执行周期期间可以更新多少执行引擎112时将所确定的松弛时间考虑在内。松弛时间可以受源应用108-1在周期开始后提供其输出所需的计算时间和/或更新管理器102执行上述计算所需的计算时间的影响。例如，对于持续500ms的执行周期，源应用108-1可能需要50ms来计算其输出。因此，在下一个执行周期开始之前，剩余450ms的松弛时间来传递应用状态部分(假设更新管理器102在相同的50ms时段内执行其计算)。松弛时间对可以在一个执行周期内更新的应用部分的数目施加了阈值。更新管理器102因此可以基于由松弛时间施加的阈值而不是全周期时间，来计算可以并行更新多少节点106。

在步骤204中执行的计算的结果可选地被显示给工程师120以供批准。例如，更新管理器102可以以指示源应用状态108-1的哪些变量需要被传递以及到哪个节点106的指示的形式来提供结果。备选地，可以仅显示选择的变量以进行比较。这些值可以由工程师120选择。不匹配的变量可以以实时更新的方式被显示。结果可以例如以表格的形式被显示给工程师120，特别是通过高亮不同节点上的应用状态之间的差异。这使得工程师120能够快速确定状态传递是否有意义或者是否存在太多差异。然后，工程师120可以验证结果并且批准在节点边界上的传递。

图3A和图3B图示了更新管理方法的上述步骤中的一些步骤。在图3A中，工程师120请求将应用从源节点106-1传递到目标节点106-2、106-3和106-4。在该示例中，部署方案是1对3部署方案，其中在源节点106-1处的源执行引擎112-1上运行的源应用108-1已被拆分成三个部分108-2、108-3、108-4，其中这些部分已分别被部署到目标(接收)节点106-1、106-2、106-3，每个目标节点具有相应的执行引擎112-2、112-3、112-4。尽管在该示例中示出了三个目标节点，但是应当理解，在其他示例中该数目可以变化。更新管理器102被示为读出源应用108-1的状态110-1和部署的应用部分108-2、108-3、108-4的状态，以便计算批量大小，如上面所描述的。在图3B中，更新管理器102将结果呈现给工程师120，工程师120批准传递。

在图2的步骤205中，在做出关于在下一个执行周期期间要更新多少执行引擎112的确定之后，更新管理器102暂停源节点106-1处的执行引擎112-1，同时检索源应用108-1的状态110-1。执行引擎112-1可以在松弛时间内被暂停，以便检索状态110-1。尽管在源应用108-1计算了当前执行周期的输出之后，源应用108-1应该在执行周期的剩余时间保持空闲，但是仍然期望在读取或写入应用状态时暂停执行引擎，以便这可以可靠地被完成，而没有其他事件干扰并且引起写入/读取冲突。

在步骤206中，更新管理器102提取与前m个执行引擎的更新相关的源应用状态110-1的部分。相关部分是应用状态110-1的那些部分，其对应于部署到目标节点106并且要在下一个执行周期期间更新的应用部分。应用状态110-1因此可以被分离成不同的包，即用于传递到相应目标节点106的状态部分。

在部署方案由工程师120提供和实施的情况下，更新管理器102可以使用与上面描述相同的技术，来分析源应用108-1和在接收节点上运行的应用部分108-2、108-3、108-4两者，以便确定这些应用部分之间的耦合强度。例如，更新管理器102可以对源应用108-1的61131控制代码进行静态代码分析，并且将其与应用部分108-2、108-3、108-4的类似分析的结果进行比较。目的是标识应用状态的哪些部分可以相互独立地被传递，即在迭代更新过程中，哪些应用状态部分需要在相同批量中被传递，或者哪些部分可以出现在不同批量中。由于分析的复杂性，该分析不是时间关键的并且可以在传递之前，即在步骤204之前被执行。更新管理器102不需要停止或暂停执行引擎112来进行该分析。

图3C示出了更新管理器102检索源应用108-1的状态110-1，并且提取该状态的部分S1、S2和S3，以在所有三个状态部分可以在一个执行周期期间被传递的情况下，分别传递到三个应用部分108-2、108-3和108-4。

在步骤207中，更新管理器102更新m个执行引擎112。这可以包括暂停m个执行引擎112，同时将传递的应用状态部分写入到那些引擎。在网络资源预留是可能的情况下(例如，使用以太网/TSN或其他手段来为网络流量引入QoS保证)，更新管理器102可以对向应用的分离部署的部分的传递设置预留。以这种方式，可以实现网络延迟的确定性上限。

图3D示出了在所有三个状态部分可以在一个执行周期期间被传递的情况下，三个应用状态部分S1、S2和S3分别被传递到目标节点106-2、106-3和106-4，以分别更新应用部分108-2、108-3和108-4。

相反，图3E和图3F图示了每个执行周期只能传递一个状态部分的场景。如图3E中所示，在一个执行周期中，更新管理器102仅从源应用108-1的状态110-1提取第一状态部分S1，并且将其传递到目标节点106-2以更新应用部分108-2。如图3F中所示，在下一个执行周期期间，更新管理器102仅提取第二状态部分S2，并且将其传递到目标节点106-3以更新应用部分108-3。重复该过程，直到所有应用部分都已被更新为止。

图3G图示了方法的阶段，其中三个应用状态部分S1、S2和S3已被分别用于更新应用部分108-2、108-3和108-4。更新管理方法的后续步骤如下。

在步骤208中，更新管理器102可选地将m个执行引擎112的输出呈现给工程师120。更新管理器102可以将来自源和目标引擎112的输入和输出的概要显示给工程师以进行视觉比较。更新管理器102可以确定部署的应用部分108-2、108-3、108-4的输出相对于源应用108-1的输出是否存在delta。如果存在delta，则更新管理器102将delta显示给工程师120。响应于确定m个输出与源应用108-1的输出相同，可以省略步骤208和步骤209。

在步骤209中，更新管理器120从工程师120接收指示delta是否被接受的输入。如果delta被接受，则方法进行到步骤210。否则，通过返回到步骤205来重复状态传递以更新m个执行引擎112。

在步骤210中，更新管理器102将m个执行引擎112的输出信号切换为生产，并且禁用源执行引擎112-1中的对应输出信号。后续，源执行引擎112-1与部署的应用部分108-2、108-3、108-4并行运行源应用108-1的剩余部分。

在步骤211中，更新管理器102通过返回步骤204，来针对下一个执行周期启动下一批应用部分的更新过程。如果传递不能在下一个执行周期中完成，则下一批可以包括剩余的n-m个应用部分或其子集。更新过程以这种方式迭代地进行，直到应用的所有部分都被更新，或者直到满意操作所需的预先确定最小数目的部分已被更新为止。

除了上述受监督的操作模式(其中工程师以例如传递请求、部署方案的批准、传递的批准等的形式提供输入)之外，本公开进一步预期了无监督模式，在无监督模式中，更新管理器(或任何自动化实体，诸如L-E-G管理节点104或编排管理器)执行一切，无需与工程师120进行任何交互，或仅具有减少或最少的交互。为此，执行方法的实体可以根据预先确定规则或标准进行操作，以做出决策。例如，部署的应用部分的输出中的delta不应超过的阈值可以被预定义，以确保应用的功能正确的行为。

根据本公开，因此提出了一种将软件应用部署到不同主机而无需停止它们的系统和方法。系统可以自动处理由目标硬件和网络引入的附加要求。工程师可以将应用将如何执行可视化以验证其输出。

可以在软件容器(例如，Docker、rkt、LXD)中执行上述软件组件。容器可以由容器编排引擎(例如，Kubernetes、Docker Swarm、Nomad)管理。这在处理软件映像方面提供灵活性，允许更好的版本控制，并且使能实例的轻松扩展。

现在参考图4，图示了可以根据本文公开的系统和方法使用的示例性计算设备800的高级图示。计算设备800包括至少一个处理器802，处理器802执行存储在存储器804中的指令。指令可以是例如用于实现被描述为由上述一个或多个组件执行的功能的指令，或者是用于实现上述方法中的一个或多个方法的指令，特别地是更新管理器和更新管理方法。处理器802可以通过系统总线806访问存储器804。除了存储可执行指令之外，存储器804还可以存储对话输入、分配给对话输入的得分等。

计算设备800附加地包括数据存储库808，数据存储库808可由处理器802通过系统总线806访问。数据存储库808可以包括可执行指令、日志数据等。计算设备800还包括输入接口810，其允许外部设备与计算设备800通信。例如，输入接口810可以用于从外部计算机设备、用户等接收指令。计算设备800还包括输出接口812，输出接口812将计算设备800与一个或多个外部设备对接。例如，计算设备800可以通过输出接口812显示文本、图像等。

预期的是，经由输入接口810和输出接口812与计算设备800通信的外部设备可以被包括在一种环境中，该环境提供用户可以与之交互的基本任何类型的用户接口。用户接口类型的示例包括图形用户接口、自然用户接口等。例如，图形用户接口可以接受来自采用诸如键盘、鼠标、遥控器等输入设备的用户的输入，并且在诸如显示器的输出设备上提供输出。此外，自然用户接口可以使用户能够以不受诸如键盘、鼠标、遥控器等输入设备施加的约束的方式与计算设备800交互。相反，自然用户接口可以依赖于语音识别、触摸和触控笔识别、屏幕上和屏幕附近的手势识别、空中手势、头部和眼睛跟踪、声音和语音、视觉、触摸、手势、机器智能等等。

此外，虽然被图示为单个系统，但应当理解计算设备800可以是分布式系统。因此，例如，若干设备可以通过网络连接进行通信并且可以共同执行被描述为由计算设备800执行的任务。

本文描述的各种功能可以用硬件、软件或其任何组合来实现。如果以软件实现，则功能可以作为一个或多个指令或代码在计算机可读介质上被存储或传递。计算机可读介质包括计算机可读存储介质。计算机可读存储介质可以是计算机可以访问的任何可用存储介质。作为示例而非限制，这种计算机可读存储介质可包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储、磁盘存储或其他磁存储设备，或可以用于以指令或数据结构的形式携带或存储所需的程序代码，并且可以由计算机访问的任何其他介质。如本文所使用的，碟和盘包括压缩盘(CD)、激光盘、光盘、数字多功能盘(DVD)、软盘和蓝光光盘(BD)，其中碟通常磁性地再现数据，并且盘通常用激光光学地再现数据。此外，传播的信号不被包括在计算机可读存储介质的范围内。计算机可读介质还包括通信介质，包括促进计算机程序从一个地方到另一个地方的传递的任何介质。例如，连接可以是通信介质。例如，如果使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)或诸如红外、无线电和微波的无线技术，从网站、服务器或其他远程源传送软件，则同轴电缆、光纤电缆、双绞线、DSL或诸如红外、无线电和微波的无线技术被包括在通信介质的定义中。上述的组合也应当被包括在计算机可读介质的范围内。

备选地或附加地，本文中描述的功能可以至少部分地由一个或多个硬件逻辑组件来执行。例如，但不限于，可以使用的硬件逻辑组件的说明性类型包括现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑器件(CPLD)等。

应当理解，上述电路装置可以具有除上述功能之外的其他功能，并且这些功能可以由相同电路执行。

申请人在此单独公开本文描述的每个单独的特征以及两个以上这种特征的任何组合，只要这种特征或组合能够根据本领域技术人员的公知常识作为整体基于本说明书来被实施，无论这种特征或特征的组合是否解决本文公开的任何问题，并且不限于权利要求的范围。申请人指出，本发明的方面可以由任何这种单独的特征或特征的组合组成。

必须注意，本发明的实施例参考不同的类别来被描述。特别地，一些示例参考方法来被描述，而其他示例参考装置来被描述。然而，本领域技术人员将从描述中得知，除非另有说明，否则除了属于一个类别的特征的任何组合之外，与不同类别相关的特征之间的任何组合也被认为由本申请公开。然而，所有特征可以被组合来提供协同效应，而不仅仅是特征的简单总和。

尽管在附图和前面的描述中已经详细图示和描述了本发明，但是这种图示和描述被认为是示例性而不是限制性的。本发明不限于所公开的实施例。通过研究附图、公开内容和所附权利要求，本领域技术人员可以理解和实现所公开实施例的其他变化。

“包括”一词不排除其他元素或步骤。

不定冠词“一”或“一个”不排除复数。此外，本文使用的冠词“一”和“一个”通常应当被解释为表示“一个或多个”，除非另有说明或从上下文中清楚地指向单数形式。

单个处理器或其他单元可以实现权利要求中列举的若干项的功能。

在相互不同的从属权利要求中列举了某些措施这一事实并不指示不能有利地使用这些措施的组合。

计算机程序可以被存储/分发在适当的介质上，诸如与其他硬件一起提供或作为其一部分提供的光学存储介质或固态介质，但也可以以其他形式被分发，诸如经由互联网或其他有线或无线通信系统。

权利要求中的任何附图标记不应当被解释为限制范围。

除非另有说明，或从上下文中清楚，否则本文使用的短语“A和/或B”旨在意指所列项目中的一个或多个的所有可能排列。即，短语“X包括A和/或B”由以下任一情况满足：X包括A；X包括B；或X包括A和B两者。

Claims (14)

1.一种计算机实现的更新管理方法，用于管理应用的应用状态从源节点到分布式控制系统的至少一个目标节点的传递，所述方法包括：

标识所述应用状态的第一部分，所述第一部分能够独立于所述应用状态的第二部分被传递；

确定在所述应用的一个执行周期期间所述第一部分能够从所述源节点被传递到所述至少一个目标节点；

通过在所述应用的第一执行周期期间将所述应用状态的所述第一部分从所述源节点传递到所述至少一个目标节点，来执行所述第一部分更新；以及

通过在所述应用后续的第二执行周期期间将所述应用状态的所述第二部分从所述源节点传递到所述至少一个目标节点，来执行第二部分更新。

2.根据权利要求1所述的方法，还包括：拆分所述应用以创建能够彼此独立操作的多个解耦的部分，每个解耦的部分与所述应用状态的对应部分相关联。

3.根据权利要求2所述的方法，其中拆分所述应用包括：分析与所述应用相关的工程数据以标识能够解耦的部分。

4.根据权利要求2或3所述的方法，其中拆分所述应用包括：使用所述应用的控制逻辑中的局部变量和/或全局变量来标识拆分点。

5.根据权利要求2至4中任一项所述的方法，其中拆分所述应用包括：使用附加变量来表示所述控制逻辑的全局变量。

6.根据权利要求5所述的方法，还包括：确定由所述附加变量的所述使用而产生的附加负载，以及应用一个或多个预先确定的规则来决定所述传递是否可行。

7.根据权利要求2至6中任一项所述的方法，还包括：确定指示所选择的目标节点的部署方案，所述解耦的部分将被部署到所选择的目标节点，以及根据所确定的部署方案来部署所述解耦的部分。

8.根据前述权利要求中任一项所述的方法，其中确定在所述应用的一个执行周期期间所述第一部分能够从所述源节点被传递到所述至少一个目标节点包括：标识所述应用状态的部分的批量，所述应用状态的所述部分的批量在该执行周期期间能够从所述源节点被并行传递到一个或多个目标节点。

9.根据权利要求8所述的方法，还包括：基于所述部分中的一个或多个部分的大小和可用网络容量，来确定要作为所述批量的一部分被并行传递的部分的数目。

10.根据权利要求9所述的方法，其中确定所述部分的数目包括：考虑计算时间以便确定松弛时间，所述传递将在所述松弛时间期间被执行。

11.根据权利要求8至10中任一项所述的方法，还包括：在所述第一执行周期期间传递应用状态部分的第一批量，以及在所述第二执行周期期间传递部分的第二批量。

12.根据前述权利要求中任一项所述的方法，包括：将由在相应目标节点上执行的所述应用的一个或多个部署的部分产生的输出与由在所述源节点处的所述应用产生的对应输出进行比较，以标识delta，以及响应于所述delta可接受的指示，切换到所述一个或多个部署的部分。

13.一种计算设备(800)，包括被配置为执行权利要求1至12中任一项所述的方法的处理器(802)。

14.一种计算机可读介质(804，808)，所述计算机可读介质(804，808)包括指令，所述指令在由计算设备(800)执行时，使所述计算设备能够执行根据权利要求1至12中任一项所述的方法。

Images