分布式软件定义的工业系统的制作方法
优先权要求
本申请要求于2017年11月16日提交的标题为“分布式软件定义的工业系统(distributedsoftwaredefinedindustrialsystems)”的美国临时专利申请序列号62/587,227和于2017年12月29日提交的标题为“分布式软件定义的工业系统(distributedsoftwaredefinedindustrialsystems)”的美国临时专利申请序列号62/612,092的优先权，上述临时申请的整体通过引用并入本文。
本文描述的实施例总体上涉及分布式和互连的设备网络内的数据处理和通信，并且尤其涉及用于定义从可配置的物联网设备和设备网络提供的软件定义的工业系统(sdis)的操作的技术。
背景技术：
工业系统被设计为捕获现实世界的仪器(例如，传感器)数据并实时地执行响应，同时可靠且安全地操作。用于这种工业系统的使用的物理环境可能是严酷的，并且会遇到温度、振动和湿度的大范围变化。由于许多静态配置的i/o和子系统缺乏在没有完全关闭设备的情况下在工业系统内进行更新的灵活性，因此可能难以实现对系统设计的小更改。随着时间的流逝，正确操作工业系统所需的增量更改可能变得过于复杂，并导致显著的管理复杂性。另外，许多工业控制系统遇到昂贵的运营和资本支出，并且许多控制系统的体系结构不是为了利用最新的信息技术进步而设计的。
物联网(iot)技术以及软件定义的技术(例如虚拟化)的发展已经导致了许多形式的电信、企业和云系统中的技术进步。实时虚拟化、高可用性且具备安全性的、软件定义的系统和联网的技术进步已经在此类系统中提供了改进。然而，iot设备可能在物理上是异构的，并且它们的软件也可能是异构的(或者随着时间的推移可能越来越异构)，使得这种设备的管理变得复杂。
尽管工业自动化和系统中已经发生了技术进步，但只研究了有限的方法来利用iot设备和iot框架。此外，由于新技术的高成本和未经证实的可靠性，工业界一直不愿在工业系统和自动化中采用新技术。这种不情愿意味着通常只尝试增量的改变；而且即便这样，仍有许多新技术表现不佳或花了很长时间才上线的例子。结果，iot技术和软件定义的技术的大规模部署尚未成功地适应工业。
附图说明
在附图中(这些附图不一定是按比例绘制的)，同样的数字可描述不同视图中的类似组件。具有不同的字母后缀的相同的数字可表示类似组件的不同实例。在所附附图的图中通过示例的方式而非限制性地图示出一些实施例，其中：
图1a图示出根据第一示例的软件定义的基础设施(sdis)操作架构的配置；
图1b图示出根据第二示例的sdis操作架构的配置；
图2a图示出根据示例的可在图1a的sdis操作架构内部署的实时高级计算子系统的配置；
图2b图示出根据示例的可在图1a的sdis操作架构内部署的边缘控制节点子系统的配置；
图3a图示出根据示例的可在图1b的sdis操作架构内部署的实时高级计算子系统的配置；
图3b和图3c图示出根据示例的可在图1b的sdis操作架构内部署的云计算和边缘计算子系统的配置；
图4图示出根据示例的在sdis操作架构内使用的控制消息总线的配置；
图5a图示出根据示例的用于部署sdis子系统的第一网络配置；
图5b图示出根据示例的用于部署sdis子系统的第二网络配置；
图6图示出根据示例的用于在sdis操作架构中动态更新数据模型的示例场景中的协议；
图7图示出根据示例的用于在sdis操作架构中生成和利用动态更新的数据模型的流程图；
图8图示出根据示例的用于将动态更新的数据模型与sdis操作架构一起合并到使用中的方法的流程图；
图9图示出根据示例的在sdis操作架构中动态建立的编排操作集合；
图10图示出根据示例的基于分布式系统构建块的级联控制应用的编排布置；
图11图示出根据示例的用于编排场景的控制策略的应用分布映射；
图12图示出根据示例的适于处理功能块应用定时依赖性的编排场景；
图13图示出根据示例的在协调器的控制下用于应用的编排资产部署；
图14图示出根据示例的用于分布式控制应用策略的编排序列的流程图。
图15图示出根据示例的用于使用分布式资源池来编排分布式任务关键型工作负荷和应用的方法的流程图；
图16a图示出根据示例的编排引擎与相关联的模块之间的编排的场景；
图16b图示出根据示例的编排引擎与包括传统模块的相关联的模块之间的编排的场景；
图17a图示出根据示例的具有可编排设备的编排的场景；
图17b图示出根据示例的具有传统设备的编排的场景；
图18图示出根据示例的在单级编排环境中的工作负荷编排的经协调场景；
图19图示出根据示例的编排的功能分层结构；
图20图示出根据示例的通用分层编排解决方案的部署；
图21图示出了根据示例的提供有从节点的使用的分层编排；
图22图示出根据示例的用于在分层编排场景中使用的从节点的工作流；
图23图示出根据示例的适于协调和实现编排自我监视功能的监视和反馈控制器的配置；
图24图示出根据示例的用于在传统设置中编排设备的示例方法的流程图；
图25图示出根据示例的工业控制应用场景；
图26图示出根据示例的由控制应用图表示的控制应用的概述；
图27图示出根据示例的用于实现控制应用的自描述性软件模块定义；
图28图示出根据示例的用于自动评价软件模块替代实现的架构；
图29图示出根据示例的用于评价软件模块的替代实现的方法的流程图；
图30a图示出根据示例的用于实现自描述性可编排软件模块的方法的流程图；
图30b图示出根据示例的用于在sdis系统实现中使用自描述性可编排软件模块的方法的流程图；
图31图示出根据示例的基于plc的工业控制系统；
图32图示出根据示例的多层现场设备总线；
图33图示出根据示例的io转换器功能；
图34图示出根据示例的io转换器冗余；
图35a-图35b图示出根据示例的用于实现多层现场设备总线的方法的流程图；
图36图示出根据示例的具有产生的警报的过程的示例；
图37图示出根据示例的动态智能警报；
图38图示出根据示例的用于动态警报控制的方法的流程图；
图39以示例图图示出自主控制-学习集成流程；
图40图示出根据示例的用于管理用于工业控制系统的新算法的自主创建的方法的流程图；
图41图示出工业控制系统环形拓扑图；
图42图示出边缘控制拓扑图；
图43图示出边缘控制节点拓扑图；
图44图示出基于边缘控制节点的环形拓扑图；
图45图示出通过基于边缘控制节点的环形拓扑的数据流；
图46a图示出根据示例的用于激活边缘控制节点的处理器的方法的流程图；
图46b图示出根据示例的用于激活cpu的方法的流程图；
图47图示出示例应用连接图；
图48图示出具有备用节点的应用的示例架构图；
图49a图示出根据示例的用于基于应用的通信模式在冗余节点上创建应用的自动冗余模块的方法的流程图；
图49b图示出根据示例的用于激活cpu的方法的流程图；
图50图示根据示例的用于通过链路而耦合到相应的网关的各个物联网(iot)网络的域拓扑；
图51图示出根据示例的云计算网络，该云计算网络与在该云计算网络的边缘处操作为雾设备的iot设备的网格网络通信；
图52图示根据示例的网络的框图，该网络图示大量iot设备之间的通信；以及
图53图示出示例iot处理系统架构的框图，在该示例iot处理系统架构上可执行本文中所讨论的技术(例如，操作、过程、方法和方法论)中的任何一种或多种。
具体实施方式
在以下描述中，公开了用于软件定义的工业服务(sdis)部署的配置、操作和适配的方法、配置和相关装置。特别地，以下的sdis部署包括基于现代操作架构的工业系统的功能，以及此类部署的派生架构或解决方案实例。例如，这样的架构和实例可以包括虚拟化控制服务器系统，其在控制或监视系统内实现边缘控制设备和控制消息总线的特征。这样的架构和实例可以进一步与iot网络的各个方面集成，涉及各种形式的iot设备和操作。
本文讨论的处理技术和配置包括用于管理各种类型的sdis架构内的操作、数据和处理的多种方式。在以下段落中提供了以下方式的概述；下面讨论了对特定实现示例和用例的进一步参考。
在示例中，建立动态数据模型以用于为sdis架构的应用、设备或传感器提供动态的特征集。这样的动态数据模型可以本质上是数据驱动的，并且可以与在开发期间通常建立的静态定义的数据模型进行对比。例如，动态数据模型可以由作为传感器全体的设备表示，从而允许该设备基于变化的因素(诸如电池和计算可用性)利用不同的输出传感器来表明自己。该动态数据模型可以在使物联网中的各种系统和数据可用的过程中起重要作用，同时是可适应的。动态数据模型的特征为设备提供了在运行时进行修改和扩展、甚至恢复为其组件的子集的能力。另外，动态数据模型可以由动态元数据、值的复杂表示(包括提供标签的概率估计而不是二元开/关状态)来体现。
同样在示例中，可以在sdis架构中建立配置以支持跨分布式资源池执行的多个从属应用(例如功能块)的整体编排和管理。通过在扩展的编排器逻辑规则集中包括附加的应用专用依赖性，可以在分布式系统配置中以嵌入式控制策略级别启用编排。通过网络带宽的动态发现、资源容量和当前状态的评价、历史信息和控制应用约束以及类似信息，可以执行多种多级优化和预测方法以完成高级编排场景。利用这样的特征，实时事件和预测也可用于将反应分级为编排事件，以维持更广泛的控制策略的在线状态。此外，与这种编排的实时优化结合的预测和约束管理可以实现嵌入式基础设施的高级别的弹性和功能。
同样在示例中，可以针对已有形式的棕场环境(其中这种“棕场”设备指已有的设备配置架构)扩展功能的编排。可以通过以下方式启用这种传统设置中的编排：在应用和设备这两个级别使用垫层来支持对无意识的应用组件和传统设备进行编排；使用分层结构来支持规模和传统设备；以及自我监控的适应，以用于管理各种设备的异构性、资源利用、规模和内置的自依赖。这种编排技术在sdis架构中的应用可以用于增加架构的可缩放性，以包括许多形式的设备、系统和行业。另外，这种编排技术允许将技术应用于客户已经对已有技术平台进行了大量投资的情况。
同样在示例中，功能的编排可以用作关键控制点，客户可以通过该关键控制点来利用硬件部署的差异化能力。可以通过自描述模块来实现这种编排，该自描述性模块提供了可部署的机制，用于在可编排分布式系统的上下文中使用自描述控制应用和软件模块。这样的自描述性模块允许在实现之间进行折衷，诸如使得当这样的特征可用时客户能够有效地使用平台特征，而当没有这样的特征时具有替代。以下示例包括适于自动评估这些折衷从而允许更有效地开发用于工业用例和部署的特征的sdis架构中的实现。
同样在示例中，本文描述的系统和方法包括多层现场设备冗余总线，其实现控制器与现场设备之间的“任意对任意”关系。控制器和io的解耦实现了简单的故障转移和冗余。通过在控制器故障的情况下使任何控制器能够访问任何现场设备来实现改善的系统可靠性和生存能力。降低的系统成本也可能是有益的，诸如通过基于小的增量投资而不是沉重的plc负担来添加新的现场设备。
同样在示例中，本文描述的系统和方法可以使用智能机器学习方法来管理警报。本文所描述的系统和方法可以：对数据进行表征，以检测可能触发警报的异常；使用数据相似度或通用因果关系对警报进行聚类，使得将它们作为一个捆包呈现，以应对警报泛滥和疲劳；或了解人对警报的响应，以便将来自动执行这些动作。
同样在示例中，本文提出了一种顺序严格的策略框架和一系列方法，以用于通过以下八个过程来管理任务关键型环境中新的闭环工作负荷的自主创建：新算法相对于过程的质量和灵敏度评估；操作约束边界的自动化建立；新算法相对于已有过程的自动化安全评估；对于更广泛的过程的自动化价值评估；对于在控制环境中的部署可行性的自动化系统评估；新应用控制策略的物理部署和监视；集成到生命周期管理系统中；以及集成到报废处理中。
同样在示例中，本文描述的系统和方法解决了在工业控制系统的边缘处过度或不足地供应计算能力的问题。过度供应计算资源会浪费金钱、电能和热能。不足地供应计算资源会牺牲可靠性以及执行控制策略的能力。所提出的解决方案使具有性能需求数据的终端用户能够“正确”确定在控制环境中供应的计算量的大小。另外，所供应的计算能力不是静态的，并且可以随着需求变化而适配以满足控制系统的需求。本文所讨论的技术允许利用了解控制策略的cpu性能需求的集中式编排系统在边缘控制节点中从初始休眠状态激活高性能cpu。
同样在示例中，公开了附加的模块互连技术。在经编排的系统中，通常，将应用定义为通过拓扑互连的一组模块。这些模块被部署在不同的逻辑节点上。每个逻辑节点可以对应于物理节点，但是，映射不必为1：1。只要满足资源要求，多个逻辑节点就可以潜在地映射到1个物理节点，并且可以在同一物理环境上部署多个模块。在示例中，解决方案可以创建模块的、基于应用的通信模式的自动备份节点。由同一层上的节点集合创建的对等网络可以协商备份的状态。该节点的社群也可以在它们之间交换备份，而对应用的其余部分没有主要影响。
其他示例将从以下附图和文本公开中显而易见。
工业自动化系统的概述
设计和实现有效的工业自动化系统提出了许多技术挑战。由于工业工厂的生命周期在许多情况下远远超过运行工厂的技术的生命周期，所以技术的管理和维护成本通常非常难以管理。在示例中，通过以下方式，可通过资源抽象使sdis部署适应工业系统中的软件和硬件资源的动态配置(和重新配置)。这样的资源抽象为更新配置提供了灵活性，而不会导致工业系统停止运行；这样的资源抽象还提供了更新随时间推移而具有改进的能力的工业系统的灵活性。
在当前公开的sdis方式中使用开放式架构以及软件与硬件之间的抽象链路提供了这些和其他技术益处，同时允许供应商将重点放在特定供应商应用的能力和实现上。所公开的开放式架构还促进了创新，降低了硬件更换的成本并消除了硬件过时的风险。所公开的开放式架构使得安全性能够被实现为sdis的固有部分，诸如通过使用硬件信任根、经签名的应用以及综合的安全性管理。这样的配置使得简化的控制系统具有固有的安全性并且具有随着时间的推移容易地集成能力的能力。这些技术改进与开放式架构和标准实现的特征相结合，使得能够在sdis中快速集成工业控制。
一些已有的方法，诸如opengroup公司的openprocessautomationforum(开放式流程自动化论坛)，已经开始开发针对工业自动化的基于标准的、开放的、可互操作的过程控制架构特征，其目标行业诸如是食品和饮料、采矿和金属、石油和天然气、石化、制药、纸浆和造纸以及公用事业。sdis和随附子系统的当前配置和功能以及技术可以通过使用该标准或类似方式而集成到工业自动化和系统部署工作中。此外，sdis和随附子系统的当前配置和功能可以在这些或其他行业中使用。因此，对以下实现的变化和变更将是显而易见的。
图1a描绘了sdis操作架构的第一示例配置。如图所示，控制消息总线112用于连接架构的各个组件，此类组件包括操作工具120、控制服务器(cs)节点130a、边缘控制节点(ecn)系统150、智能i/o控制器系统165、基本i/o控制器系统160、网关系统170和控制站115。各种现场设备(151、161、166、171)连接到各个系统(150、160、165、170)。下面进一步讨论该操作架构的一些示例用例和配置。
在示例中，操作工具120可以包括以下方面：程序开发工具、历史工具、人机接口(hmi)开发、控件和操作工具。可以用在控制服务器节点130a(如图2a进一步描绘)中操作的各个虚拟机131a来实现操作工具120的各个方面。
在示例中，控制服务器节点130a可以包括各种虚拟机131a的各个方面，这些虚拟机通过管理程序层132a进行协调，并且利用主机操作系统133a和计算机硬件架构134a的特征进行操作。控制服务器节点130a可用于实现编排135a的各个方面，涉及机器编排和操作应用编排两者。下面参考图2a提供对控制服务器节点130a的进一步详细讨论。
在示例中，ecn系统150可以包括来自在特定硬件(例如，x86或arm硬件实现)上操作的ecni/o控制器(例如，节点150a、150b)的编排(例如，编排实现)的各个方面。下面参考图2b提供ecn系统150及其在对各种连接的设备(例如，现场设备151a、151b)的编排中的作用的进一步详细示例。
在示例中，智能i/o系统165可以包括来自智能i/o控制器(例如，控制器165a、165b)和随附操作系统的工业控制的各种可配置方面，以用于各种设备(例如，现场设备166a、166b)的控制或访问。同样在示例中，基本i/o系统160可以包括来自基本i/o控制器(例如，控制器160a、161b)和随附操作系统的工业控制的各种操作方面，以用于各种设备(例如，现场设备161a、161b)的控制或访问。
在示例中，网关系统170可以包括用于从网关(例如，网关170a、170b)连接到其他设备网络或部署的各种可配置方面，以用于各种设备(例如，现场设备171a、171b)的控制或访问。在各种设备中，传感器(“s”)和执行器(“a”)组件的作用在整个现场设备中(例如，在现场设备151a、151b、161a、161b、166a、166b、171a、171b上)被标记。将理解，附加数量和类型的设备和组件也可以耦合到各种系统150、160、165、170。
图1a所描绘的操作架构被配置为实现传统企业架构中看到的许多相同属性，诸如hw/sw模块化、sw可移植性、互操作性、应用可扩展性和计算可缩放性。除此之外，可以部署此架构中引入的新基础设施框架组件，最值得注意的是在cs和ecn系统的实现中，以便支持本文讨论的sdis技术的集中式和分散式概念。
例如，使用ecni/o控制器(例如，在ecn节点150a、150b中)与在过去的五十年中不断发展的当前的dcs(分布式控制系统)和plc(可编程逻辑控制器)控制系统在架构上有很大的不同。ansi/isa-95自动化接口堆栈的该任务关键性部分中的任何架构改进都必须遵守过程控制的严格且有弹性的要求。利用本文所述的sdis架构，ecn系统不仅可以保持这些严格的操作要求，而且可以保持开放、可互操作，同时允许工业用途通过持续的技术进步来安心、可靠、安全且快速地引入或刷新这些系统。本sdis架构能够在整个操作和控制堆栈中实现更广泛的生态系统参与、创新和产品定制。例如，可以为ecn系统提供控制分解，以用作基本控制系统构建块，用于放大控制功能自定义并针对各种用例提高处理灵活性。
图1b描绘了sdis操作架构的第二示例配置。以与图1a所示类似的方式，图1b的配置图示出控制消息总线112，该控制消息总线112用于连接操作架构的各个组件，这些组件包括云组件(作为控制服务器工作的实时高级计算系统130b、以及云计算服务180)边缘组件(具有组成边缘计算节点191a、191b、191c、第一边缘计算平台193和第二边缘计算平台195的边缘生态系统190)和控制站115。具有传感器和执行器的各种现场设备192、194连接到(边缘生态系统190和边缘计算平台193、195中的)相应的边缘计算节点。上面讨论的操作目标和特征也适用于图1b的配置。
作为图1a中引入的sdis操作架构的进一步扩展，图1b的配置图示出如下场景，其中跨各个云和边缘组件的控制器和服务器的操作通过相应的虚拟机虚拟化，被部署有相应的容器，被部署有相应的应用，或其任何组合。结果，图1b的sdis操作架构允许对各种硬件设置(包括arm和x86硬件架构两者)进行可重新配置且灵活的部署。图3a中描绘出实时高级计算系统130b的进一步突破，并且在图3b和图3c中分别讨论云计算服务节点180和边缘计算节点193的进一步突破。
sdis架构的另一方面可以涉及实时通信的使用。主控于服务总线结构110上的控制消息总线112可用于实现多个级别上的网际互联融合。例如，控制消息总线112可以实现具有时间灵敏度的以太网传输的使用，诸如通过基于以太网的时间灵敏度联网(tsn)开放标准(例如，ieee802.1tsn任务组)。此外，控制消息总线112的使用可以允许在云服务器机架级别以及跨大型联网的边缘节点或者边缘节点构架上实现更高的性能和规模。
在sdis架构中，实时服务可以通过控制消息总线112(诸如，通过以太网tsn)在实时物理传输之上操作。控制消息总线112可以适于(例如，通过使用开放平台通信统一架构(qpc-ua)、对象管理组数据分发服务(dds)、opendxl、开放连接性基金会(ocf)或类似标准来)解决iot设置中的已有的中间件或通信栈的异质性，以实现设备到设备的无缝连接，以便解决iot部署的新兴实现。
在示例中，可以通过控制服务器(cs)设计来实现用于sdis架构的编排管理。图2a图示出在sdis操作架构(例如，以上参考图1a讨论的操作架构)内的控制服务器子系统(例如，实现cs节点130a)的配置。具体地，图2a提供了cs节点130a及其组件虚拟机131a、管理程序132a、主机操作系统133a和硬件架构134a的进一步图示；如图所示，cs节点130a被示为单个节点，但是可以包括两个或多个节点，并且许多虚拟机跨这些节点而分布。
在示例中，cs节点130a可以包括编排135a，该编排135a由机器和操作应用编排来促进。可以使用机器库136(诸如用于实现平台管理的数据库)来限定机器编排；可以使用控制功能库142和操作应用库144来限定操作应用编排。例如，控制标准设计141和集成的(和安全的)应用开发过程143可用于定义库142、144。
在示例中，cs节点130a被设计为在虚拟化环境中主控isa级别l1-l3应用。这可以通过在管理程序132a之上运行虚拟机(vm)131a来实现，其中每个vm都封装了兼容未来机载能力环境(face)的堆栈和应用，或非face应用，诸如人机接口(hmi)、历史工具(historians)、操作工具等。在示例中，兼容face的vm可以提供封装在vm中的整个face堆栈(操作系统、face区段和一个或多个便携式组件)。封装意味着每个vm可以使其自己的虚拟资源(计算、存储、内存、虚拟网络、qos、安全策略等)通过管理程序132a与主机和其他vm隔离，即使每个vm可以正在运行不同的操作系统，诸如linux、vxworks或windows。
为了最大化虚拟化和稳健性的益处，便携式组件的相关组可以被分组在兼容face的vm中并且使用多个兼容face的vm。使用这种方式可以跨cs硬件分散工作负荷，并隔离特定于该组组件(诸如网络)的资源，同时仍允许应用通过网络与其他虚拟化的物理设备(诸如ecn)进行通信。跨vm分配face便携式组件通过使彼此不相关的组件相互隔离增加了安全性、提供了对故障的稳健性、允许独立更新功能、并简化了集成，从而允许各独立供应商向系统提供完整功能的vm。
在进一步的示例中，可以在单独的vm(或vm组)中将层2组件与层3组件分开，以提供各层之间的隔离，并允许在各层之间实现不同的网络连接、安全性控制和监视。对便携式组件进行分组还可以为集成提供好处，以允许多个供应商解决方案容易地组合在一起从而运行多个虚拟机并在它们之间配置网络。同样在进一步的示例中，诸如windows，linux以及其他兼容intel架构的操作系统(例如vxworks实时操作系统)之类的附加操作系统可以各自被部署为虚拟机。cs节点130a内的当前公开的vm的其他配置也可以实现其他技术益处。
在示例中，可以在cs节点130a中利用云基础设施平台，诸如适于使用诸如linux、kvm、openstack和ceph之类的开源标准和实现的实时高级计算系统。例如，云基础设施平台可以适于解决关键基础设施需求，诸如平台和工作负荷的高可用性、连续24/7操作、确定性/等待时间，高性能、实时虚拟化、可缩放性、可升级性和安全性。云基础设施平台还可以适于满足软件定义的特定于工业自动化的关键基础设施要求。
图2b图示出在sdis操作架构(例如，以上参考图1a讨论的操作架构)内的分布式边缘控制节点(ecn)子系统的示例配置。在示例中，ecn节点150a、150b驻留在isa-95级别1/级别2中，并被定位为基本的基础hw/sw构建块。
在示例中，ecn节点150a、150b经由(例如，位于ecn机柜的外部的)传感器或执行器或智能设备支持到单个现场总线设备的单个输入或输出。可以通过ecn机柜或机架系统来扩展ecn设备架构，从而解决了已有的专有dcs系统的布线、升级和容错限制，其中该ecn机柜或机架系统扩展分布式控制系统的开放性和灵活性。在示例中，ecn架构在标准posixos中操作，其中兼容face的堆栈被实现为软件模块区段或软件模块组。在下面的示例中引用了用于部署这些软件模块的各种方式。
ecn节点150a、150b可以支持用于编排和服务的各个方面的各种软件定义的机器(诸如下面针对图6所描绘的编排)。在示例中，ecn节点150a、150b可以与各种硬件安全特征和可信执行环境集成，诸如英特尔
图3a图示出可在图1b的sdis操作架构内部署的实时高级计算系统130b的更详细配置。具体地，图3a的配置图示出在管理程序层132b上操作的各个虚拟机131b的操作，各个虚拟机131b可以包括不同部署类型的虚拟机、容器和应用。当vm、管理程序和操作系统在硬件架构134b(例如，商用现货(cots)x86架构)上执行时，可以使用主机操作系统133b来控制管理程序层132b。实时编排135b的各个方面可以集成到计算系统操作的所有级别中。因此，x86计算系统可以适于协调本文讨论的基于云或基于服务器的sdis功能或操作中的任意方。针对cs节点130a讨论的功能或硬件配置的其他方面也可以适用于计算系统130b。
图3b和图3c分别图示出可在图1b的sdis操作架构内部署的云计算180和边缘计算193子系统的更详细配置。以与图3a中描绘的类似的方式，图3b和图3c中描绘的一系列虚拟机181、196、管理程序层182、197、主机操作系统183、198和cotsx86硬件架构184、199可以适于实现相应的系统180、193。在实时编排的控制下，可以使用应用和容器来协调基于云和基于边缘的功能。针对ecn节点150讨论的功能或硬件配置的其他方面也可以适用于边缘计算节点193。边缘计算节点193可以实现控制功能以控制现场设备。
本文描述的系统和技术可以集成“移动边缘计算”或“多路访问边缘计算”(mec)概念，其访问一种或多种类型的无线电接入网络(ran)以允许内容、服务和应用的速度增加。mec允许基站充当能够在边缘网络中传递高度个性化的服务的智能服务中枢。mec为包括在下一代sdis操作环境中使用的设备在内的各种移动设备提供了接近、快速和灵活的解决方案。作为示例，由欧洲电信标准协会(etsi)出版为etsi第11号白皮书、yunchaohu等人撰写的国际标准书号979-10-92620-08-5、网址为http：//www.etsi.org/news-events/news/1009-2015-q9-news-new-white-paper-etsi-s-mobile-edge-compiiting-initiative-explained的论文“移动边缘计算，5g的关键技术(mobile-edgecomputing,akeytechnologytowards5g)”描述了mec方式，其全文并入本文。将理解，可以将5g/下一代无线网络、软件定义的网络和网络功能虚拟化的其他方面与本sids操作架构一起使用。
图4图示出在sdis操作架构内使用的实时服务总线的示例配置400(例如，控制消息总线112的配置)。如本文所讨论，该配置允许支持各种处理控制节点。例如，控制消息总线112可以用于将各个控制处理节点410(包括节点410a、410b、410c上的各种硬件和软件实现)以及基于云的服务或(多个)控制服务器130a与各种边缘设备420(例如，i/o控制器150、160、165或边缘计算节点191、193、195)连接起来。
在示例中，控制消息总线112可以被实现为支持具有速率单调控制要求的分组级、确定性的控制网络。这些特征通常由专有的分布式控制系统(dcs)、监督控制和数据采集(scada)或可编程逻辑控制器(plc)组件提供。这些系统中的大多数被设计为设计参数，这些设计参数限制了节点和数据元素的数量，几乎没有能力动态管理设施内通常是封闭和隔离的网络的数据的数量和质量。在这些系统的生命周期中，由于昂贵的控制系统基础设施的潜在不灵活性和有限的可缩放性，严重限制了实施新兴的新用例的意愿。
利用先前的方式，开源和基于开放标准的服务总线中间件选项都已经成熟，以至于解决方案提供商的任务关键型生态系统已经将这些技术视为用于构建可缩放、高度冗余、容错、实时的系统的“同类最佳”能力，而成本仅为历史成本的一小部分。这已经激发了新用例的实现，这些新用例针对离散和连续处理而实现，其中商品级硬件和开源、基于标准的软件已经融合在一起，以实现实时计算方法，同时保持基于面向服务的架构的设计原则。
在示例中，控制消息总线技术可以通过在网络的平台节点之间和之内启用时间敏感联网(tsn)和时间协调计算(tcc)从而在硬件级别启用实时计算来进一步扩展。专有和基于开放标准的解决方案都可以与支持商品硬件的增强功能集成在一起，包括利用由opc-ua(opc统一架构)和dos(数据分发服务)组提供的行业标准，以及诸如sercos标准之类的专有实现，在sercos标准中，在机器人和机器控制应用中，对离散运动控制的硬实时要求是强制性的。
在示例中，控制消息总线和整个sdis架构也可以与工业互联网协会(iic)特征集成在一起。这些可以包括用于tsn的工业使用的各种制定和测试标准，其可以通过显著减少分组级等待时间和抖动来增强基于dds的解决方案和基于opc-ua的解决方案的性能和qos。此外，对象管理组(qmg)和opcfoundation标准的各个方面可以定位为支持增加的opc-ua和dds实现模型的集成，这些实现模型利用了opc-ua的信息建模以及dds在架构设计中的qos和性能能力。新用例可以包括分析法和自主能力。
在示例中，可以将sdis架构与软件定义的网络(sdn)特征的使用集成。sdn是向着软件可编程网络的发展，该软件可编程网络将控制平面与数据平面分离，以使网络和网络功能更加灵活、敏捷、可缩放，并且对联网设备、供应商和服务提供商的依赖性更低。与sdis相关的sdn的两个关键用例包括：服务功能链，其允许动态插入入侵检测/防御功能，以及动态重新配置，用于响应于诸如大规模停机(诸如区域维护、自然灾害等)之类的事件。此外，可以将sdis架构与sdn控制器集成在一起，以便使用诸如开放vswitch数据库管理协议(qvsdb)之类的联网协议来控制虚拟交换机。sdn功能的其他用例可能涉及动态网络配置、监视以及虚拟化和动态系统中网络功能的抽象。
图5a图示出用于sdis子系统的示例部署的第一网络配置500。第一网络配置500图示出在冗余的一对主机(节点510a、510b)上组合控制器存储和计算功能的按比例缩小的小型部署选项。在此配置中，控制器功能(用于控制应用或实现)在节点510a、510b上处于活动/备用状态，而计算功能(对于所有其余进程)处于活动/活动状态，这意味着可以部署vm以便在任一主机上执行计算功能。
例如，lvm/iscsi可用作跨计算节点复制的卷后端，而每个节点也具有用于临时存储的本地磁盘。处理器带宽和存储器也可以被保留用于控制器功能。当需要较少的处理和冗余时，此两节点解决方案可以提供较低的成本和较低的占地面积解决方案。
图5b图示出用于sdis子系统的部署的第二网络配置。第二网络配置550可以为专用存储节点提供高容量、可缩放性和性能。与第一网络配置500相比，第二网络配置550允许将控制器、存储和计算功能部署在单独的物理主机上，从而允许存储和计算能力彼此独立地缩放。
在示例中，第二网络配置可以由(例如，由控制器节点520a、520b协调的)高可用性(例如，ceph)集群中的多达八个存储节点(节点530a-530n)和每存储节点八个磁盘的配置提供，高可用性群集为计算节点提供映像、卷和对象存储。例如，可以支持多达100个计算节点(例如，节点540)，每个计算节点具有其自己的本地临时存储以供vm使用。如将理解的，可以使用本sdis架构来实现多种其他网络配置。
sdis架构以及随附的数据流、编排和下面扩展的其他特征也可以利用机器学习、认知计算和人工智能的各个方面。例如，可以将sdis架构与参考平台集成，该参考平台在基于硬件的安全性、可互操作的服务和开源项目中具有基础，包括使用大数据分析法和机器学习以用于网络安全。sdis架构可以利用不可变的硬件元件来证明设备信任，并且基于通过机器学习增强的过滤器来表征网络通信量行为，以将不良通信量与良性通信量分离。
sdis架构的各个组件可以与丰富的安全能力的集合集成在一起，以便在现实世界的工业设置中实现可互操作和安全的工业系统。例如，这样的安全能力可以包括基于硬件的信任根、受信的执行环境、受保护的设备身份、虚拟化能力以及可以在其上建立稳健的实时安全性架构的密码服务。在以下各节中将进一步讨论功能性sdis架构部署中此类组件的配置和功能。
数据模型的概述
在示例中，sdis架构可以进一步与各种数据模型集成，以用于管理来自传感器、执行器和其他已部署组件的数据。如果不知道如何生成数据或在何处生成数据、正在收集什么测量值、或其他特征，则数值数据的时间序列流的用途有限。数据模型可用于在许多域中提供此类信息的上下文，甚至在用户希望混淆数据身份的极端情况下也是如此。
可以定义数据模型以提供数据结构的表示。还可以定义数据模型以允许不同的相关方定义多个对象以及这些对象如何相互作用或彼此相关。例如，语义数据模型可以在多个域中使用，并且辅助在sdis架构内的各种信息系统中进行处理和存储。
在示例中，语义数据模型可以定义以下组件的任意组合的各个方面：
·元数据：(例如，描述数据关于什么内容的信息)。
例如，数据流或数据点可能具有包含名称的元数据，诸如“温度”。另一条元数据可能是位置“第二层，杆j2”，以指示数据的来源。此外，此类元数据可以是灵活的和可扩展的。
·分类：在分类中，数据可以描述数据点之间的类别和关系。分类可以包括关于对一条数据执行分析法的信息、以及关于该数据如何与特定站点中的其他数据或设备相关的信息。可以为系统定义标签库，以保证多个设备的互操作性和对多个设备的支持。
·对象结构：对象结构可用于描述对象可能并应当拥有哪些元数据和分类。
·数据流：数据流可以描述数据转换和数据流，并且这种数据流可以是抽象的或实体的。在进一步的示例中，数据流可以依赖于诸如rest之类的标准定义或方式。
·数据存储：特定数据存储配置的数据存储和使用可能会影响数据模型以及数据生产者和消费者的表现。
如下面的示例所扩展的，sdis架构可以提供通用的数据模型，以解决跨应用和机器的数据传播中的异构性。如下面还讨论的，可以在sdis架构中利用动态数据模型来提供数据结构的抽象表示，并进一步允许不同的相关方定义灵活的数据对象、它们的表示及其相互关系。这些和其他语义数据模型对于许多信息系统部署中的处理和存储可能是必不可少的。
动态数据模型
如上所述，数据模型可以是用于iot部署(诸如sdis实现)中的基本组件。数据模型是不同结构和流的数据和关系的抽象。基于该实现，可以通过简单的即时标记(例如，在projecthaystack中使用，一种用于开发构建设备和操作数据的命名约定和分类的开源计划)或结构/类和数据流的扩展定义(例如，通常在设计阶段期间和系统开发之前建立这样的定义)来实现数据模型。数据模型在许多系统中都很重要，因为它为开发人员、设计人员、架构师和部署技术人员提供了一种描述和查找数据源的机制。
大多数数据模型涉及时间和工作(以及多次迭代)以产生定义。此外，大多数数据模型是静态的，并且需要相当多的修改和迭代，以便向已有的模型添加新的标签、组件或连接，从而经常使它们向后不兼容。这防止了在部署期间数据模型的大量变更，其用于描述由数据的应用(诸如，在数据可视化、分析法或供应工具应用中)使用的标签。
尽管已有的解决方案在定义数据模型方面可以提供有限的灵活性，但是这种解决方案不是动态的。例如，尽管数据设计者可以定义具有许多特征的设备，其中一些特征是可选的，但是特定的特征可能在运行时期间不被变更。这使得数据模型的创建、更改和维护非常复杂，尤其是在工业使用环境中。
根据定义，数据模型创建趋向于是静态的。意思是，一旦定义并实现了数据模型，对结构(例如，数据模型的结构，而不是数据值)的任何变更通常都需要用于该数据模型的新版本的代码的开发工作和部署。但是，这并没有解决应用、设备或传感器何时具有动态特征集的场景。示例将是作为传感器全体的设备，其可以基于电池和计算可用性而将自身表明为不同的输出传感器。这样的设备可以包含多个物理传感器(接近度、接触、光、蓝牙、温度等)，并且可以报告房间中的占用情况。然而，如果由于某种原因该设备需要节省功率或遇到故障模块，则该设备可以恢复为其组件的子集。在这种情况下，动态数据模型(以及动态元数据和特征)的概念非常有价值，甚至可以通过复杂的表示来实现，诸如标签的概率估计而不是二元的开/关状态。动态数据模型的概念还可为预测何时在iot环境中部署(或应当部署)编排提供有价值的输入。
以下技术使得能够创建和部署动态数据模型，以解决sdis架构和类似设置中的这些和其他技术注意事项。在动态数据模型中，数据设计者可以标识一组必填字段，诸如名称、单位、类型等。另外，数据设计者可以保持该定义开放以供节点和模块添加元数据(或任何类型和数量)，或者该定义可以限制可以添加的内容和可以由谁添加。
在示例中，当节点看到在数据流中发生的某些行为时，该节点可以向传感器查询其元数据扩展规则。例如，模块可以使用分析法来生成预测性维护输出。作为计算的一部分，如果模型应用非监督学习，则该模型可以检测到某个感测数据流随着时间的流逝变得越来越重要并且应该将其添加到特征集。特征集对于分析法计算很重要，并且取决于应用，特征集还可能导致实时要求。
例如，将该标志添加到元数据将允许tsn交换机升级网络的通信量优先级以支持学习算法。当添加了动态元数据时，将为数据分派有效期或刷新期。这将保证数据需要继续支持该特定特征，否则该特征可以不再有效并且可以被相应地更新。替代地，可以实现废弃机制，该废弃机制将允许系统在元数据不再有效或不再需要时废弃多条元数据。
在示例实现中，每个数据流被分派给数据流管理器。数据流管理器可以是生成数据的设备，或者是位于雾/云中的虚拟实现。数据流管理器携带动态元数据的策略。当系统中的另一个模块或节点需要作用于动态数据模型时，该另一个模块或节点将联系流管理器。然后，流管理器可以向其提供具有等效密钥的令牌，以允许数据流管理器在数据流管理器看到并分析通信量时添加和更新元数据。
在进一步的示例实现中，系统可以添加出处元数据。出处提供了所有权和修改的痕迹，节点可以使用该痕迹来了解流的历史或仅元数据的部分。
图6图示出根据示例的用于建立动态数据模型的协议。在该示例中，传感器610在数据流630中产生流数据。该数据流是由多个节点(例如，监视数据流630的服务器640、650)获得并处理的。在数据流630中产生的传感器数据被标记以指示传感器610支持动态数据建模。然后，(例如，在服务器640上操作的)数据模型管理器获得并处理该传感器数据。
数据模型管理器可以驻留在网络中的任何地方，只要它对传感器610以及被允许修改主体传感器的数据模型的其他模块和设备可访问。例如，当数据向上游流动时，设备(例如服务器650)可以运行一组分析法以确定在用于算法的特征集中是否应考虑数据流。由于系统中的变化，设备确定传感器610生成的数据流现在对于控制机器人620的过程有价值。然后，设备将带有其凭证的请求发送到数据模型管理器，以请求修改传感器数据流或向传感器数据流添加标志，该标志将指示与机器人手臂的相关性。数据模型管理器确定所讨论的算法是否有权请求这种更改。
使用预定义的策略，数据模型管理器向设备发送命令，以请求实施算法所请求的修改。这些更改将基于策略生效，或者可以是请求的一部分。新添加到数据模型的元数据可以具有进一步的后果，诸如影响其他因素，诸如(例如，涉及启用tsn通信的)连通性qos。类似地，如果由于某种原因，算法或应用不再对传感器数据感兴趣，则可以修改数据模型以省略所讨论的标签。该请求可以包括标签的完全移除或者甚至是在进一步的数据被分析之前的暂时挂起。
图7图示出用于在sdis操作架构中生成和利用的动态更新的数据模型的示例过程的流程图700。如所描绘的，下面的流程图包括多个高级操作，其可以由一个或多个系统或子系统(例如，图6的配置中的服务器640、650)执行。然而，在sdis架构，以下操作可以在各种计算或控制器节点之间适配，以用于与各种连接的传感器和执行器一起使用。
在流程图700中，操作包括监视从受控系统中的传感器或执行器提供的数据流(操作710)。可以持续地在数据流中，利用对来自数据源的数据的采样或任何数量的监视方式来提供这种监视。基于该监视，可以从数据流中检测一个或多个模式(操作720)。例如，可以针对一个或多个模式分析数据值、数据值趋势、数据值置信度或概率或由一种或多种数据值类型和源指示的其他值的组合。在示例中，可以针对该模式检测而采用机器学习、人工智能或规则。
一个或多个检测到的模式可以用于标识数据模型变更(操作730)。例如，某些数据值的组合可以用于触发要添加到数据模型的聚合数据值类型的添加；同样，例如，某个数据值的趋势或置信度可以导致数据值类型被删除或更改。然后，可以将标识出的数据模型改变并入到数据模型中(操作740)，并且被部署以在各种系统组件中使用。因此，可以基于数据模型更改在系统部署中执行后续的系统操作(包括系统命令和工作流)(操作750)。作为该数据模型更改的结果，也可能发生其他类型的数据分析和系统操作适应。
作为上文讨论的动态数据模型更改的扩展，数据流中标签的存在还可以用于表示数据值的置信度或数据类型。例如，假设使用特征选择组件来确定特定数据流与分析功能的相关性。特征选择组件可以确定该数据流的相关性得分。作为进一步的示例，特征选择组件可以为数据流中的特定信息字段生成相关性得分0.8。这样的相关性得分可以用作在元数据中定义的置信度水平，其将被添加到数据模型中。
以类似的方式，相同的数据流可以具有非常低的相关性得分(0.4)，以用于诸如占用率的另一信息字段。另一个设备或算法可以在过滤器被设置为高置信度的情况下向设备查询其元数据。结果，设备将返回与相关性得分0.8相关联的元数据，但是将省略相关性得分为0.4的元数据。
在这样的示例中，不仅数据模型是动态的，而且用于评价特定数据字段的相关性得分也可以是动态的，并且可以定期重新计算或基于事件重新计算。在又一示例中，相关性得分不被定义为单个值，而是由具有与多个值相关联的一组条件的向量表示。向量的示例可以如下所示：
·标签：“算法”：“占用率”
·置信度向量[0.7,0.3,0.8]
·上下文向量[“7：00am-5：00pm”,“5：01pm-8：00pm”,“8：01：pm-6：59am”]
在该示例中，存在具有三个相关联的上下文的三个置信度水平。上下文可以与数据的时间一样简单，或者更复杂以提供基于事件的表达式。
继续前面的示例，考虑一种场景，其中光传感器用于确定智能建筑物部署中的房间占用率。传感器值可以提供正常办公时间期间的占用状态的准确指示。然而，在清洁人员工作时间之后，此时多个照明器材快速打开和关闭，这不是正常现象，传感器值可以因为清洁人员的异常活动而被抛出。然而，在8：00pm之后，此时通常清洁人员不在，照明的存在可以再次用作占用率的准确指示。
动态数据模型可以允许基于生成的上下文和数据(或数据的属性)对标签进行有用的添加和删除。这可以允许sdis部署基于那些动态标签添加通信量优先级、策略甚至路由决策，而无需重新创建新的数据模型来添加或删除那些扩展。
从开发人员和应用的角度来看，为了支持动态数据模型，每个设备将支持、修改合适的查询并将其添加到此类设备的数据模型。设备还将支持用于基于一组标准返回数据模型的查询。结果，用于修改、添加和返回数据模型的设备接口被用于数据模型的运行时修改。
在进一步的示例中，数据模型也可以在多个设备和节点之间同步。例如，一种算法可以基于来自某一部署中的建筑物的一部分的数据，确定通常放置在会议室中的某个传感器现在与占用率算法非常相关。如果是这种情况，则可以修改传感器的数据模型以反映该新发现。另外，可以要求其他传感器执行一段代码以确定这些传感器是否表现出相似的行为。如果特征提取显示相似的行为，则也可以扩展该数据模型。结果，即使未在所有传感器上都经过验证，应用开发人员甚至系统集成商也可以允许该修改发生。这样的能力可以用作准确性/验证与假设相似的传感器数据是有价值的并且应该被相应地路由和管理之间的折衷。
还可以允许将被动态添加到数据模型的标签或元数据进行老化(例如，衰减)并且(通过降低相关性得分)删除或降级，除非设备或算法继续验证这样的元数据的需求和相关性。这样的老化可以允许对即使开发人员未识别出也已经过时的元数据进行自然修剪。在基本实现中，老化可以严格地基于时间；然而，其他实现可以包括高级概念，包括基于缺乏使用的老化。类似地，如果请求添加的设备或算法没有消耗来自传感器的数据，则元数据可以被老化或存档(例如，继续可用，但是不被赋予任何优先级)。然而，元数据的周期性使用(尽管系统做出查询或其他qos决策)可以使元数据中的关注度保持最新。
图8图示出用于在sdis操作架构中维护动态数据模型的各个方面的示例方法的流程图800。在示例中，该方法可以包括：标识用于数据模型评价的一个或多个条件的可选前提条件(操作810)；针对根据数据模型提供在数据流中的数据，通过数据流从一个或多个传感器获取数据(操作820)；标识用于数据模型修改的一个或多个阈值(操作830)；以及使用(多个)模式或(多个)规则和(多个)标识出的阈值来评价来自(多个)传感器的数据以用于数据模型修改(操作840)。
该方法还可包括：定义用于数据模型修改的特征添加、变更或删除(操作850)；向数据模型管理器请求对数据模型修改的批准(操作860)；从数据模型管理器接收对数据模型修改的批准并处理对数据模型修改的批准(操作870)；将数据模型修改并入用于一个或多个传感器或数据流的数据模型中(操作880)；以及基于数据模型修改在系统架构中实现对数据处理的变更(操作890)。
可基于以上讨论的其他示例、场景或条件来扩展这些动态数据模型操作中的任意方。此外，可以结合本文公开的sdis架构的功能编排或其他管理的特征来组合维护和利用动态数据模型的附加方面。
功能编排的概述
图9图示出通过在sdis操作架构中使用可组合应用系统层(csl)来动态建立的一组编排操作900的示例。可以利用csl来实现控制功能和应用的安全设计和编排，以便支持工业操作。
在示例中，csl维护功能块990的库980，每个功能块标识控制环逻辑和应用组件。每个功能块可以与其他功能块互操作。功能块可以具有多种实现，使其具有可移植性，从而使其可以在各种平台架构上运行，并在特殊特征(例如，硬件加速器)可用的情况下利用特殊特征。在示例中，csl为边缘节点(例如，ecn)的集群提供控制功能；在进一步的示例中，csl为控制服务器中的vm或sdis操作架构中的其他计算点提供控制。
在示例中，过程工程师(或其他操作员)通过组合和配置来自库980的已有的功能块990来定义控制流和应用。这些功能块990可以表示应用逻辑或控制循环(例如，控制循环970、数据存储、分析法模块、数据获取或执行模块等)、控制模块或任何其他计算元件。因为这些功能块990是可重用且可互操作的，所以仅当需要新的功能块时才需要编写新的代码。在进一步的示例中，可以使用这样的功能块来实现端到端逻辑，包括使用图形化拖放环境的控制流或端到端应用。
从该应用设计开始，csl生成编排计划940，该编排计划940指定所需的功能块以及对用于执行这些功能块的计算点的要求。如以下各节中所讨论的，编排920可以包括将编排计划940映射到可用的计算和通信资源的过程。可以基于控制标准设计910进一步适配编排920(例如，以使所得编排符合各种控制法则、标准或要求)。
在示例中，csl维护跨sdis网络的计算和控制资源的映射930。映射930包括从数据中心中的虚拟机到控制点以及所附接的传感器和执行器的各种计算点的拓扑。映射930还包括控制点的硬件能力和动态特性。映射被定期更新，从而允许系统不断适应组件故障。编排920和控制环970使用监视逻辑950和功能部署960进行通信。监视逻辑950输出来自现场设备或控制循环970的信息，该信息用作映射930的输入。功能部署960用作针对控制循环970的输入或状态设置。
当操作员部署新的应用定义时(例如，编排920从控制标准设计910接收输出)，编排920确定如何使功能块990最适合映射930中的可用资源集合，并部署实现功能块990的基础软件组件。端到端应用的部署可以包括例如，根据需要，在服务器内创建虚拟机，将代码注入控制循环(例如，控制循环970)，以及在组件之间创建通信路径。编排920也可以是动态的，以允许在计算资源发生故障时迁移功能块，而不需要系统范围的重启。另外，可以推送对组件实现的更新，从而导致代码根据需要被更新。
csl还可以并入安全性和隐私性特征，诸如以便与参与设备(包括边缘节点或控制服务器)建立信任。在进一步的示例中，csl可以与用于装载新设备和用于废弃过时设备的密钥管理集成在一起。csl可以将密钥传递给功能块960以实现与其他功能块960的安全通信。csl还可以传递安全的遥测和控制、所部署的代码的完整性和隔离执行以及功能块990之间的通信完整性。
在以下部分中进一步讨论在sdis的编排架构内开发的编排功能的附加示例。
分布式任务关键型工作负荷的编排
当今的编排技术主要由功能、应用、虚拟机或容器技术执行。然而，对于当今的控制策略实现，通常不在低等待时间、高频任务关键型时间框架内管理分布式应用之间的固有依赖性。通常，对于嵌入式系统，由于对运行时的管理应用依赖性的技术限制，历史上没有应用动态编排。
以下技术解决了定义用于工业系统的实时任务关键型控制策略的分布式工作负荷的编排。经编排的控制策略可以在当前正在定义的新的分布式控制系统(dcs)设计中操作，并且可以应用于离散、连续和批量的制造操作。对于这些系统，实时任务关键型控制应用可以遵循iec61499标准来构建，并且可以表示为多个经调度和经协调的同步或异步、事件驱动的构建块应用的组合。在应用功能独特的情况下，可以以特定的顺序和定义的系统等待时间边界内的频率一致地执行构建块。
与以下方式相反，许多已有的嵌入式应用通常在专用的固定用途硬件上运行。传统的应用编排不考虑应用处理对构成完整控制策略的其他应用构建块的依赖性，其中在完整控制策略中，总的计算、存储器、存储和调度需要一起执行以供任务关键型控制策略无错执行。
在示例中，sdis架构的特征可以适于支持跨分布式资源池执行的多个从属应用(功能块)的整体编排和管理，以便实现分布式系统配置中嵌入式控制策略级别的编排。这为操作技术环境提供了控制策略编排能力，同时以预期的降低的总成本提高了整体系统性能。例如，示例编排方法可以并入动态网络发现、在任何编排动作之前的资源模拟、以及与用作编排器规则集决策树的一部分的全局资源优化和预测相结合的模拟。
分布式资源池可包含跨越以下范围的应用：(a)在单个本机设备上运行的单个应用，其中第二冗余应用在附近本机设备上可用；(b)在多个本机设备中运行的多个经协调应用；(c)在单个虚拟机上运行的多个经协调应用，其中虚拟机在单个嵌入式设备或服务器上运行；(d)跨多个虚拟机运行的多个经协调应用，其中每个虚拟机都在专用嵌入式设备或服务器中运行；(e)跨越一个虚拟机中包含的多个容器的多个经协调应用，其中该虚拟机在专用嵌入式设备或服务器中运行；或者(f)跨越多个容器的多个经协调应用，其中这些容器在多个嵌入式设备或服务器上运行。这些应用场景的任何混合也可以适用。
在示例中，编排可以包括资源的测量或资源的保留，诸如节点上的(例如，cpu上或诸如fpga或gpu之类的专用计算块上的)计算资源、特定的设备能力(对传感器/执行器、安全设备(例如tpm)、预装软件的访问)、节点上的存储资源(存储器或磁盘)、网络资源(可能通过tsn保证的等待时间或带宽)，等等。
扩展的编排器规则集可以被定义为包括标准计算、存储和存储器度量之外的标准，诸如以便指定应用周期时间、应用运行时、应用输入/输出信号依赖性或应用进程顺序(例如，指定哪个(哪些)应用在其他应用块之前或之后运行的强制性顺序)。该编排技术可以在分布式应用控制策略级别上提供利用低成本商品硬件和软件以在控制策略级别上实现更好的系统性能、同时以较低的成本跨以isa级别l1-l3运行的多个应用实现新级别的系统冗余和故障转移的能力。此外，在更广泛的控制策略级别上的编排灵敏度可以以更低的成本使得嵌入式系统有新级别的高可用性。这可以导致用于经编排和经协调的控制应用的一般系统和应用的正常运行时间增加，同时与传统方式相比，减少了在更高的isa级别上的生产操作的计划外停机时间。
对于将系统冗余设计到自动化配置中的系统，以下编排技术还可以使附加维护任务能够发生(无需生产停机)。这些技术使得能够在利用了平台不可知的虚拟化和容器化的供应商硬件之间执行控制策略的情况下提高互操作性。这些技术还利用当前、历史和模拟结果来优化用于实时操作的操作技术环境的工作负荷放置。此外，这些技术可以利用对未来编排事件的预测来预先计划工作负荷放置。
在示例中，分布式资源池被定义为跨联网计算资产的计算、存储、存储器的组合，并出于执行应用控制策略目的添加了(处理分派之前和之后的)功能块调度频率、等待时间容限。例如，控制策略(或应用)可以由物理分布的、经协调的构建块集定义，其具有非常严格的时间、块到块调度以及用于执行的运行时要求。这些构成块在时间上的编排在构成整个应用控制策略的所有构成块的执行次序、处理等待时间和完整执行周期方面进行协调。
图10图示出基于分布式系统构建块1010的配置的示例级联控制应用1040的编排布置。具体地，该图描绘了基于iec61499功能块标准的示例构建块集合1005。图10所示的应用展示了在现代分布式控制系统中应用的通用分层策略。对于该示例，出于说明目的，图示出全部应用块的子集(块1010)；但是，所示的所有应用块都可以作为用于特定实现的依赖项包括在内。
对于图10中所示的控制应用1040的示例，功能块a、b、c和d(1022、1024、1026、1028)以级联控制设计配置在控制子系统中。每个通用构建块(独立的功能块或应用)执行指定的算法作为分布式控制策略的一部分，以用于控制输出(流量阀1030)。在该示例中，控制功能块输出被发送到下一个功能块作为其输入值。当由于某些系统异常使特定块脱机或“断线(shed)”时，到从属构建块的链路被移交给操作员以进行手动控制。
为了使级联策略起作用，必须维持控制循环的每个块的应用循环时间、应用运行时、应用输入/输出信号依赖性以及应用进程顺序。当这些链接在生产中丢失时，随之而来的是效率大大降低的操作，并且代表工业水平上的主要固有损失。使用本技术的扩展的编排器规则集的定义可以解决这些资源问题中的每一个。
扩展的编排器规则集中的能力分层使得能够添加更高级的算法，这些算法直接影响生产成本、提高产品质量和流程效率，同时通过松散耦合的设计原则集保护工作人员的安全，该设计原则集使各个应用能够脱机并降级到较低的控制级别以保护整体操作。如果没有该应用控制的分层，新的解决方案将难以实施，并且操作将更容易发生事故。此外，在控制策略级别上对这些应用资产的编排进一步改善了总体正常运行时间和系统性能，这直接有助于制造和过程操作。
常规的it编排策略通常将提供以动态方式在系统中移动各个应用资产(功能块)的能力；但是，在本示例中，在定义特定控制策略的所有功能块之间编排分布式功能块应用的协调。集体功能块链路和相关联的状态信息被维护以便跨系统资源编排这些构建块，从而使应用保持在线，并避免脱离更基本的安全控制状态。
图11描绘了用于包括四个应用的编排场景的控制策略的示例应用分布映射，其中在设计1120中针对本机、虚拟机、容器和虚拟机部署中的容器描绘了应用冗余。如所图示，应用资产的编排可以包含要考虑的用于动态分配资源的不同部署选项，受到各种计算、存储、存储器和应用约束。
注意，对于图11所示的情况，在编排场景1110中定义的应用(应用1至4)被指定为以不同的频率运行。在此示例中，循环和运行时依赖性是在运行时的编排决策中的主要因素。具体地，在所描绘的示例中，可以在30分钟的窗口内编排应用1，并保留控制策略执行；可以在5秒的窗口内编排应用2，并保留控制策略执行；可以在1秒的窗口内编排应用3和应用4，并保留控制策略执行。如果错过用于编排的执行窗口，则应用链路断开，并且控制策略降级为安全(safe)状态，直到操作(operations)再次关闭循环。
图12图示出适于处理功能块应用时序依赖性的示例编排场景1210a、1210b。如图所示，在定义可以在哪里部署应用以维持操作无错误的更多标准资源度量之外，应用周期、运行时依赖性和当前状态也起重要作用。例如，以相对慢的周期时间和频率执行的控制策略可以在具有较低计算资源的设备中运行，并且不需要与该控制策略的其他从属应用块共同定位。相反，可能需要将需要以非常快的周期时间和频率执行的应用全部都共同定位在同一设备，以使控制策略无错误地运行。
在图12的示例中，编排场景1210a示出了可以跨系统的多个独立节点分布应用1-4(应用部署1230a)以执行过程1220a的场景。相比之下，编排场景1210b示出了由于周期和运行时限制可以未跨系统的多个独立节点分布应用1-4(应用部署1230b)的场景。相反，必须针对任何编排事件将应用1-4一起编排，以成功执行过程1220b。
图13描绘了示例编排资产部署，其示出了在编排器1310的控制下对编排资产(应用1320)的各种部署。具体地，该示例图示出基于可用系统资源的一种潜在的动态应用结果。如所描绘的，示例涵盖了vm，container、vm+container和本机节点部署。在图13的示例中，节点1、6、10和14处于活动状态，展示了同一编排中的不同应用如何在不同的系统部署类型中操作。
图14描绘了用于分布式控制应用策略的示例编排序列的流程图1400。在该示例中，每个功能块应用驻留在系统的不同计算节点中。具体地，图14实现了编排方法，该方法除了计算、存储和存储器以及网络资源可用性之外，还考虑了控制循环的每个块的应用周期时间、应用运行时、应用输入/输出信号依赖性以及应用进程顺序，以便有效地允许在不中断控制执行的情况下跨可用资源进行控制应用的编排。
各个构建(或功能)块的编排发生在上文讨论的图14所描绘的完整控制策略应用的定义的边界条件的边界内。此外，当前状态和历史信息与单独的功能块应用约束的定义的集合结合时，为执行用于资源分配的各种多级优化方法提供了一种手段，该手段还可以包括针对更广泛的控制策略的编排可能性的预测。通过将预测和约束管理与实时优化相结合，可以实现嵌入式基础设施的高级别的弹性。
在示例中，用于监视分布式控制应用的功能块的操作(操作1410)可包括监视各种形式的当前和历史状态数据。这可以包括监视：可用的计算开销；可用的计算速度；可用的存储；可用的存储器；应用周期时间；应用运行时；应用链路依赖性；应用进程序列依赖关系；或特定于应用的编排错误。
在又一个示例中，用于更新预测的操作(操作1420)可以包括：编排优化＝每个控制策略的f(当前状态数据、历史状态数据、约束)；编排优化＝每个应用构建块的f(当前状态数据、历史状态数据、约束)；或者，编排预测＝每个应用构建块的f(当前状态数据、历史状态数据、约束)。
在进一步的示例中，可以评价用于检测针对应用构建块的系统异常的操作(操作1430)。这些可能会受到针对每个应用定义的约束，诸如：计算开销允许限制；计算速度最低要求；存储最低要求；存储器最低要求；应用周期时间限制；应用运行时限制；用于输入和输出依存性的应用链路依赖性；用于输入和输出变量的应用进程序列依存性；用于编排事件的应用系统错误触发。
在又一示例中，操作可以评价是否需要对任何功能块的编排(操作1440)。例如，如果违反了应用约束l..n，则需要编排事件。在又一示例中，操作也可以评价控制策略编排是否可行(操作1450)。这可以评价：是否需要在定义的约束内将应用移动到另一个节点，是否由于应用依赖性而需要移动多个应用，并且如果需要，该组应用是否可以分配以及如何进行分配。在又一示例中，如果编排不可行，则可以实施降级或断线控制策略(操作1460)，并且可以相应地更新活动的功能块概要文件(操作1480)。
在又一示例中，响应于验证需要功能块的编排并且控制策略编排是可行的，执行操作以编排控制策略的构建块应用(操作1470)。如果编排成功，则这导致预测的重置(操作1490)。如果编排失败，则这导致使用降级或断线控制策略(操作1460)以及更新活动的功能块概要文件(操作1480)。
图15图示出用于使用分布式资源池来编排分布式任务关键型工作负荷和应用的示例方法的流程图。基于先前的示例，此方法可以实现基于(例如，如参考图10-图13所描述的)扩展的应用特定依赖性集合动态地编排分布式应用和从属应用的组的能力。该方法还可以实现在提交编排策略之前动态地分析和模拟网络带宽的能力。该方法还可以提供在编排事件发生之前对其进行预测并主动为控制策略工作负荷编排规划潜在的经优化的资源放置的能力。
在流程图1500中，示例操作包括：标识应用特定的依赖性(操作1510)；基于所标识的依赖性动态地创建分布式和从属应用的编排组(操作1520)；以及使用编排组预测编排事件(操作1540)。在示例中，预测编排事件包括在示例场景中动态分析和模拟网络带宽(或其他资源)(操作1530)、以及在该示例场景中分析编排事件的发生。
基于预测的编排事件，可以执行操作以定义和修改扩展的编排器逻辑规则集。这些操作还可包括检测预测的编排事件(操作1550)、以及基于预测的编排事件优化资源放置(操作1560)。例如，参考图14讨论的技术可以并入变更后的编排策略的各个方面。
针对传统(棕场)环境的编排
编排是将用户对应用的要求(可能由许多处理、联网和/或存储组件组成)与物理世界的能力相匹配并部署应用(诸如通过配置物理世界以及分配和配置应用组件)的行为。编排通常应用于企业环境，以将高度可缩放的服务部署到同类和虚拟化环境中。这些应用被设计为在该环境下操作。
当编排应用于iot环境，尤其是那些具有已有的(“传统”)设备(例如“棕场”部署)的环境时，该问题以几种方式改变：通常存在大量设备；目标设备的集合是高度异构的；某些应用组件可能未设计用于编排；某些硬件设备可能未被设计成用于编排解决方案；并且某些设备可能是专有和封闭/固定功能的设备。
使用常规方法，软件模块必须符合要编排的特定api，使得它可以被正确地部署和配置。通常，为了接收被编排的软件，硬件节点运行编排软件并向正在执行的软件提供特定的api。因此，可能出现的几个问题包括：如何缩放许多设备和应用；如何允许编排未被设计成在不修改的状态下编排的软件模块；如何允许将软件模块编排到传统硬件节点或原本无法支持编排堆栈的硬件节点上；以及如何自我监控一组异构物理节点以管理资源利用。
在示例中，以下技术使得能够通过将代码封装在知晓编排的垫层内部来编排不知晓编排的代码。在进一步的示例中，以下技术使不知晓编排的设备能够参与编排。相反，现有方式没有考虑引入了明显不同问题和要求的编排问题(特别是异构环境中的端到端编排)。同样，在进一步的示例中，编排自我监视可以用于实现自立和自组织的编排，该编排从失败中学习并将反馈并入更好的编排方法中。
编排技术允许在考虑资源能力以及应用要求和约束的情况下将分布式iot应用的各个软件组件跨可用硬件资源集合动态部署。当前的编排技术倾向于假设(1)软件组件被设计成通过实现编排api来编排，以及(2)设备被设计成通过提供编排中间件来接收可编排软件。本文中的技术通过将这样的传统组件包装在可编排的组件内部来实现对传统软件组件的编排，这提供了插件架构以便以标准或自定义机制与传统软件交互。例如，标准插件可以从编排api接收通信端口号，并通过配置文件或环境变量在诸如web服务器之类的标准软件上设置端口号。同样，例如，可以编写自定义插件以支持专有软件。
图16a图示出编排引擎1610a与相关联的模块之间的编排的示例场景。如图所示，编排引擎1610a部署了两个可编排模块1620a、1630a。两个模块各自使用编排api(分别为1640a、1640b)来从编排引擎1610a接收配置参数。例如，如果模块11620a是http客户端并且模块21630是http服务器，则模块11620a可以接收该模块需要与模块21630通信的端点信息，诸如ip地址和端口号。在某些情况下，编排引擎1610a将模块21630应绑定到的端口号提供给模块21630，而在其他情况下，模块21630在绑定后可以向编排引擎提供通信信息。在任一情况下，两个模块都使用api(例如，api1640a、1640b)建立通信参数并变成连接状态。
图16b图示出编排引擎与相关联的模块(包括传统模块)之间的编排的示例场景。编排引擎1610b部署两个不同的模块(1620b和1660)，一个知晓编排，另一个是不知晓编排的传统模块。在这种情况下，编排引擎1610b还与传统模块1660一起部署垫层1650。该垫层1650理解与传统模块1660相关联的任何自定义配置机制。例如，如果传统模块1660是apacheweb服务器，则可以将垫层1650配置为通过编排api1640d协商端口号，然后在启动apache服务器之前使用配置文件、命令行参数或环境变量(或类似机制)来配置web服务器的端口号。可编排模块1640c中的客户端将使用可编排api1640协商客户端通信参数，来以与先前示例相同的方式运行，因此将能够连接到apacheweb服务器。
在示例中，可以通过将每个传统设备与可编排设备配对来以类似方式处理由传统硬件设备执行的工作负荷。作为示例，图17a图示出具有可编排设备的编排的场景。可编排设备1710a上的代理收集有关该设备的可用资源的信息，并将其作为遥测报告给编排引擎1720a。典型的可编排设备能够向编排器表示其能力，并且能够从编排器接收工作负荷执行请求并执行工作负荷1730a。传统设备不支持这些功能，因此与可编排设备配对。
作为进一步的示例，图17b图示出具有传统设备1780的编排的场景。每个可编排设备(例如，设备1750b)向编排系统表示传统系统的能力。当编排系统在传统系统上请求工作负荷时，配对的设备负责使该功能在传统设备上执行。这可以采取远程过程调用或自定义api的形式。结果，编排引擎1720b能够匹配并部署适当的工作负荷到设备。对于传统设备，与传统设备1780配对的可编排设备1750b上的代理能够发现传统设备1780的存在并测量该传统设备的能力(例如，通过rpc机制)。然后，该信息由代理作为遥测1740b传递给编排引擎1710b。当编排引擎1720b传递用于传统设备1780的工作负荷1730b时，代理1760b将其部署到传统设备1780(例如，通过rpc机制)。因此，封装机制允许传统硬件和软件两者都参与现代iot编排解决方案。
编排技术通常提供扁平资源集的调度和管理。被编排的资源可以包括计算(实体或虚拟设备)、联网(实体或虚拟接口、链路或交换设备)或存储能力(数据库或存储设备)。编排可以采取任务(执行单位)编排、容器编排、虚拟机编排、网络编排或存储编排的形式。或者可以是所有这些同时并且采用端到端应用编排的形式。
图18描绘了在单级编排环境中的工作负荷编排的经协调场景。该单级编排环境显示了所有平台均等地参与编排的场景：每个节点(例如，节点1830a、1830b、1830c)将其可用资源描述给编排引擎1820(通常是集中式的，诸如在编排器1810处)，该编排引擎1820通过发送遥测来执行调度功能，并且编排引擎1820分派多个节点的子集来运行总体应用工作负荷的多个部分。因此，如图18所示，各种工作负荷(1821a、1821b、1822、1823a、1823b)被分派给各种节点1830a、1830b、1830c，并使用相应的代理1840a、1840b、1840c执行。该方式提供了扁平的编排结构，并且意味着各个节点1830a、1830b、1830c的能力的最低水平，从而每个节点可以完全参与编排过程。
然而，可以通过将编排分为各种功能和功能操作来使编排成为分层的。图19描绘了编排的示例功能分层结构，图示出应用编排1910如何提供编排的控制顶级域。如果在顶级完成端到端应用编排，则可以将网络编排1920、虚拟机编排1930、任务编排1940和存储编排1950的细节委托给子编排模块。子编排器可以用于确定如何优化每个子问题并配置每个子域中的资源。
图20图示出通用分层编排解决方案的示例部署。图20中的部署描绘了子编排器2040a、2040b、2040c的通用分层结构，其中可调用可编排设备池来实现整个应用的多个部分。
在示例中，每个子编排器(例如2040a-2040c)从给定的可编排设备池中的可编排设备(例如2050a-2050g)接收遥测。遥测指示该池中可用的资源。子编排器聚合该遥测并将其转发给顶级编排器2010。顶级编排器从子编排器(2040a-2040c)接收遥测，该子编排器(2040a-2040c)向该顶级编排器2010通知该池中可用的总资源。然后，顶级编排器2010基于遥测将总工作负荷的子集分派给该编排引擎2020。子编排器进而将工作负荷的子集调度到池中的每个可编排设备上。注意，尽管在此示例中使用了两个编排级别，但是可以实现附加的级别。
在某些场景中，在资源可以同时跨时间和空间(在池之间)共享的假设下，协调器2010有可能超额预订一个池中的资源。另外，子编排器可以能够从未充分利用的池中借用设备以便临时处置负荷过剩。例如，在图20的示例中，如果集群12030a变得过载，则可以从集群22030b或集群32030c借用一个或多个从设备。
虽然图20中描述的方式假定所有设备都是可编排的，但实际上，许多可编排设备可以是成本非常低的微控制器，具有最少的存储器和存储。这些低成本感测解决方案中的可能成百上千的每个组又可以由功能更强大的设备控制。为了解决该情况，图21图示出使用从节点提供的分层编排的示例。
图21的场景提供了与上文在分级编排场景中讨论的类似的方式，其中主编排设备2110可以代表许多其他从节点的能力。这样的能力可能包括，例如，从特定传感器设备进行感测的能力，或利用特定fpga部件执行计算的能力。代理将这些能力报告给编排器2110、该编排器2110将工作负荷分派给该单独的主可编排设备。然而，主节点不一定运行该工作负荷，而是可以将其发出到具有工作负荷所需的个体能力的从节点(例如，节点2150a-2150h)。该过程对编排器2110透明地发生，其只关心工作被执行。
为了实现该主/从关系，在从节点上实现了一些简单的基元，包括：(a)检测，使得必须由主节点检测从节点的存在，并且还必须检测从节点的故障(以及因此所部署的工作负荷)；(b)发现，使得从节点上的可用资源必须可由主节点发现，并且此类信息有助于确定可以部署的工作负荷的类型和数量；(c)部署，使得主节点能够在从节点上部署工作负荷(例如rpc、固件部署等)。
图22图示出用于在分层编排场景中使用的从节点的示例工作流。在示例中，该节点将等待从引导其集群的主可编排设备接收发现请求(操作2210)。在此期间，该节点可能正在以较低功率状态等待。该请求可以包括某种密码质询，诸如将被从节点加密的现时数(nounce)。当从节点接收到该请求时，从节点可以发回一些证书(操作2220)以证明该节点属于该集群。例如，节点可以用私钥加密现时数并发回结果。从节点还可以以能力集合的形式将遥测发送到集群引导者(操作2230)。然后，从节点将等待其指令(操作2240)，可能以要执行的工作负荷的形式。当从节点接收工作负荷时(操作2250)，从节点可以需要重新编程自身(操作2260)，可能是刷新其可编程存储器；在重新编程之后，从节点然后可以继续执行工作负荷(操作2270)。
在分层解决方案中的调度可能会引入复杂性。例如，主节点上的代理必须小心地正确描述它所代表的资源之间的关系，使得当资源实际跨许多从属节点分布时，编排器不会错误地认为这些资源实际上共同定位在同一节点上。
上文的分层编排机制允许创建本质上更加异构的动态sdis解决方案，包括允许使用原本无法完全参与编排的资源有限(且价格便宜)的组件。此外，此部署允许将较少数量的基于ia的节点(昂贵的资源)用作主节点，从而为每个群集提供编排机制。
在非常大的iot框架中，虽然编排就在特定硬件组件上部署什么软件方面选择的解决方案最初可能是正确的，但随着时间的流逝，这可能会发生变化。另外，必须监视系统的整体容量以确保系统的可用资源不会耗尽。因此，需要监视整体解决方案是否有诸如cpu过载之类的软件和硬件问题，并采取适当的步骤来加以解决。以下技术实现自立和自组织的编排，该编排从失败中学习并将反馈并入更好的编排中。
在进一步的示例中，可以将类似于控制循环的检查和反馈机制添加到上文讨论的编排方式中。各个组件，包括软件、联网、存储和处理，可能具有内置的监视机制，或者可以需要频繁轮询以启用这种管理。这可以通过扩展编排层来提供，该编排层跟踪所有可用资源，以包括需要监视什么操作的标签，诸如cpu、存储器、应用响应延迟、应用行为、网络延迟、网络带宽、特定硬件。
图23图示出适于协调和实现编排自我监视功能的监视和反馈控制器2310的示例配置。在示例中，监视和反馈控制器2310从各种客户端节点2350、2360收集软件数据2320、硬件数据2330和网络数据2340。这些客户端节点2350、2360进而在编排服务器2370的指导下操作经编排的操作和工作负荷。
在示例中，监视客户端节点2350、2360中是否有硬件和软件过载。例如，如果设备的cpu或存储器达到容量的50％，则可以密切监视该设备。如果容量达到80％，则可以更换设备，或者可以将工作负荷迁移到与正在执行的工作负荷更匹配的设备。如果存在硬件依赖性，则可以添加附加节点来承担软件负荷。在类似示例中，还可以监视网络通信量。如果看到大量未知通信量或看到少于预期的通信量，则系统可以检查客户端节点的性能。这样的检查还可以建议黑客入侵或网络连接丢失。
监视和反馈控制器2310使得能够循环回到动态地控制行为的管理服务器。反馈回路不仅用于客户端节点，还用于服务器。例如，监视机制可以监视服务器节点的性能，可能是通过监视服务器之间的网络通信量。例如，如果监视服务器群集健康并确保被选择的领导者始终可用的gossip协议正在消耗过多的带宽，则可以动态修改协议参数以更好地适应当前的服务器数量、链路条件和通信量水平。
监视和反馈控制器2310还可以并入用于从故障中学习的逻辑。如果节点持续故障，则可能存在底层硬件问题，并且该节点可以被调度以进行维护。如果在特定物理区域中有许多节点发生故障，则可以检测该模式，并且这些节点可以被调度以进行人工检查。在进一步的示例中，节点可以监视它们自身是否存在潜在问题。例如，每个节点可以监视自己，而不是要求监视解决方案轮询各个节点以确定它们的健康。例如，如果节点的内存不足，则它可以将其状况报告给中央监视器。
自我监视和管理的其他方面也可以与编排一起被并入。系统可以为单个节点指定维修调度安排。可以在一定数量的操作时间之后调度每个节点以用于服务，此时，该节点将被调度器从可用于调度的节点集合中取出。
在进一步的示例中，自我监视功能还可以提供容量计划。例如，如果联网或处理使用量接近容量，则可以通知操作员增加容量。该系统可以通过指定需要多少资源和需要哪种资源来帮助操作员进行计划。例如，系统可以指定需要可以在其上部署任务的附加节点，并且这些节点应具有某一最小存储器和存储容量。这种自我监视功能允许编排解决方案具有高度的可缩放性，并易于适配到基础设施中。
图24图示出用于在传统设置中编排设备的示例方法的流程图2400。如图所示，流程图2400包括用于在棕场环境中配置和操作编排的一系列端到端动作，其具有与传统组件建立通信、建立经组织的编排以及操作、监视和调整编排的特征。将理解的是，出于说明目的，以高水平提供了流程图2400，并且上文描述的附加配置和使用操作可以集成在操作流程中。
如图所示，流程图2400包括用于建立编排垫层以配置传统软件模块的操作(操作2410)，经由编排垫层api将配置传送到传统软件模块的操作(操作2420)以及经由可编排设备代理从传统硬件设备收集遥测的操作(操作2430)。进一步的配置操作(包括在图16a-图17b中描绘和讨论的操作)可以包括可编排硬件设备和可编排软件模块的配置。
还如图所示，流程图2400包括用于组织组件的分层结构的操作(操作2440)，诸如经配置的传统组件和可编排组件。组织可以包括将组件组织成各种分层结构(操作2450)、执行各种从节点组件的检测、发现和部署(操作2460)。还可以发生进一步的检测和分层组织(包括在图18-图22中描绘和讨论的操作)。
同样如图所示，流程图2400结束于用于基于遥测和来自分层结构中的组件的其他配置数据将工作负荷分配到组件的分层结构中的各种组件的操作(操作2470)(包括图18-图22中描绘和讨论的操作)。流程图2400进一步用于诸如通过在经组织(分层)的编排的组件之间(包括用图23中描绘和讨论的操作)收集和监视软件数据、硬件数据和网络数据来允许自我监视和配置更改的操作(操作2480)；作为响应，编排器、管理员或其他实体可以向经组织的编排的各种组件提供反馈和控制的操作(操作2490)。
自描述编排组件
在工业解决方案的开发中，工程师可以将解决方案设计为可以部署到iot系统中的模块的图。图25图示出示例工业控制应用场景，该场景具体地描绘了通过用加热器2536加热周围的油套来维持水箱2530的温度的问题。水的温度和油的温度由相应的传感器2532、2534监视以便控制过程。可以在其上部署软件模块的一组计算节点2520可以是可用的，其中的一些可以连接到系统中的物理传感器和执行器。
在该示例中，控制工程师可以设计控制系统应用2510以用于执行功能操作，诸如作为级联控制循环来控制温度，该级联控制循环由可以在可用计算节点上部署的软件模块的图组成。传感器模块可以从主传感器2532读取数据，该主传感器2532从水中的传感器读取值。该值被馈送到试图满足特定设定点的pid(比例积分微分)控制器模块(例如，具有一个或多个比例、积分或微分控制元件的控制器)的输入。该pid控制器的输出被馈送到缩放模块，该缩放模块的输出建立另一个pid控制器的设定点。该第二pid控制器从一模块接收其输入，该模块从油中的传感器(例如，从传感器2534)读取数据。第二pid控制器的输出被发送到控制加热器元件2536的执行器模块。在示例中，pid控制器中的任何一个可以是并入作为任意数量的功能操作的一部分的比例、积分或微分控制(单独或任意组合)的一种控制器。
为了正确地部署这样的配置，控制工程师描述控制应用以及控制应用内的功能和操作。以下方式讨论了用于定义用于描述控制系统应用的语言的配置的技术。以下方式进一步讨论了可以在其上实现控制系统应用的自描述模块的使用；以及可以利用语言和自描述模块将有效的解决方案部署到计算节点上的编排器。
下列方式特别地实现自配置和自描述模块的使用，以用于在本文讨论的sdis环境中的编排的增强实现。如在此讨论的，自描述模块允许通过阐明需求或约束来更好地理解需要部署哪些平台资源并且哪些平台资源使编排更容易。自描述模块提供了模块的自描述与端到端应用的自描述的分离。自描述模块还提供了表达给定软件模块的多个替代实现的能力以及在多个实现之间进行权衡的能力。可以在用于自动评价模块和应用的替代实现之间的折衷的架构中实现这种方式，从而帮助用户在ia(指令架构，例如x86、arm)设备上编排经优化的应用。
在以下示例中，模块是编排器部署的应用的组件。模块具有描述其输入和输出、要求和其他事项的模块清单(如图13所示，并在表1的示例中引用)。应用由输入和输出连接在一起的模块的集合组成。使用应用规范(如图26所示，并在表2的示例中引用)描述了一种应用。在示例中，该应用规范由用户创建以便定义端到端应用。应用规范向编排器提供输入以及任何适用的模块清单。应用规范也可以用于指定模块、它们的互连以及在部署这些模块时必须满足的任何附加要求。因此，以这种方式使用模块清单和应用规范能够实现并实施端对端应用的功能操作。
在许多设置中尝试了为应用部署定义端到端应用的概念；但是，现有的编排方式注重it方面的考虑，并没有提供用于在工业系统中使用的灵活方式。这种方式没有考虑涵盖从边缘设备到云部署的所有内容的端到端应用。此外，现有的编排系统不允许用户表达用于给定软件模块的替代实现，或者未向用户提供用于评价或表达多个替代实现之间的权衡的手段。以下自描述模块和自描述语言使得能够更好地理解需要部署哪些平台资源，并且因此通过阐明适当的要求或约束来使编排更容易和更准确。
在示例中，除了可以在其上实现控制系统应用的自描述模块之外，还可以扩展sdis实现以提供用于描述控制系统应用的语言。从这两个元素，编排器可以将工作解决方案部署到各个计算节点和资源上。因此，本文描述的技术提供了：(1)用于建立用于可编排模块的自描述以便将端到端应用与各个模块分开的机制；(2)用于允许系统在模块的多个替代实现之间动态选择以用于部署的机制；以及(3)用于允许系统推理出在不同情况下哪种替代实现为最佳的机制。
图26描绘了由示例控制应用图2600表示的控制应用的概况，该示例控制应用图2600在传感器和执行器的级别上表示。如图所示，控制应用由控制工程师定义为软件模块的图，其中每个模块的输出(例如，来自传感器a2610和传感器b2620的输出)连接到其他模块的输入(例如，到致动器c2640和pid控制器2630的输入)。控制工程师还可以指定其他因素，诸如模块参数的起始值。控制工程师可以在软件库中找到这些软件模块，或请求由it部门实现自定义模块。在示例中，可以通过使用图形用户界面或其他基于视觉的表示来定义该图。例如，示例控制应用图2600可以由控制工程师定义以便反映工业系统的输入、输出和控制器。示例控制应用图2600可以反映物理系统的连接，并用于完成控制应用的各种功能操作(以及实际变化、测量和效果)。
图27描绘了用于实现自描述性控制应用(诸如图26中描绘的控制系统模块(pid控制器2710))的示例软件模块定义。在示例中，用于该软件模块的代码是在下列几个假设的情况下编写的，包括该模块不知道它将部署在哪个节点上，并且该模块可以通过一组命名接口与相邻模块通信。接口可以是定向的，以便允许面向连接的协议(其通常具有客户端和服务器端点)，该协议通常以定向的方式建立，但不一定是指数据流的方向(可以在某一个方向或两个方向上流动)。
在进一步的示例中，该模块的代码具有对在其上与相邻模块进行通信的信道的要求(例如，网络要求2740)(带宽、等待时间、抖动等)。然而，该模块不知道它将与什么模块通信或这些模块将被部署到什么节点。模块不知道用于其通信端点或其他通信端点的通信参数。模块可以需要一定数量/种类的处理资源、存储器资源和存储资源，并且可以需要其他硬件和软件依赖性(库、指令集、芯片组、安全协处理器、fpga等)。此外，模块可以允许指定一组经命名的起始参数(例如，参数2720)。
为了使该代码具有自描述性，模块开发人员可以创建用于与软件模块一起使用的模块清单，其中该模块清单用于标识和描述用于执行软件模块的控制环境的关键特性。在示例中，特性可以包括诸如以下的特征：(a)(pid控制器2710的)通信接口，包括每个接口的名称、类型(客户端、服务器、发布/订阅)、协议(dds、opc-ua、http)或qos要求(如果有)(如果有的话)；(b)参数和默认起始值(例如，控制参数2720)；(c)平台要求(例如，指令集、os、ram、存储、处理)(例如，要求2750)；(d)依赖性(例如，库、硬件、输入信号等)(例如，依赖性2730)；(e)部署要求(安全性、隔离性、隐私性、编排风格)；(f)代码模块的签名(例如，签名2760)。
用于控制系统应用的示例模块清单和在图27中执行的模块可以用以下定义表示：
表1
在进一步的示例中，控制工程师可以利用一个或多个软件模块的库来创建或定义控制系统应用。例如，图形用户界面(gui)可用于设计控制系统应用的图(例如，类似于图26中所示的控制应用图)。gui可以利用模块清单来指示每个代码模块的细节，并说明各个代码模块可以如何彼此连接。此外，用户可以利用拖放和其他图形指示方法来选择适当的模块，并连接和配置它们以设计与图26所示的控制应用图类似的图。
被编译成用于控制系统应用的应用规范的该信息的结果可以被编码为类似于以下示例的应用规范格式：
表2
以该方式定义的应用规范允许控制工程师：选择一组要使用的模块，指定超出任何默认值的参数的值，指定超出模块本身指定的约束或资源的任何附加的约束或资源，以及指定将模块链接在一起的方式。另外，应用规范可以为链路分派特定的参数，诸如，将主题名称分派给发布/订阅通道，或者将端口号分派给服务器端点(使通信端点可以从应用外部访问)。
在示例中，应用规范还可以为应用中的相同功能指定替代实现(例如，由不同模块实现的功能的每个版本)。例如考虑模块的针对两个不同硬件架构实现相同功能的两个版本。模块编写者可以在模块清单中指定这些替代，诸如以下示例中所示：
表3
在另一个示例中，控制工程师可以在应用规范中指定这些替代，如下所示：
表4
在该示例中，编排器可以通过选择适当的软件模块实现，部署在这两个架构(x86或arm)中满足这两个约束中的任一者的某一个架构的节点上。
自描述性模块表征的使用可以应用于其他种类或类型的资源。例如，在可以在通用cpu、gpu或fpga上实现算法的情况下，可以应用这种自描述性表征。在该情况下，也可以在应用或模块规范中提供打分，以便指示哪个模块是优选的。打分可以既是特定于算法的又是特定于数据/应用，因此需要代表开发人员或控制工程师的某些知识。此外，打分的使用可以使控制工程师能够通过利用针对特定la硬件平台(例如fpga或神经网络处理器(nnp))进行了优化的软件模块(如可用)来优化所选择的控制应用。
自描述性模块表征的使用可以被进一步推广以考虑更多一般资源。例如，针对存储器资源优化出算法的第一版本，而可以针对存储资源优化出算法的第二版本。在该情况下，第一版本具有小的存储器资源要求和更大的存储要求，而第二版本具有大的存储器资源要求和小的存储要求。编排器可以基于在可用的节点集上可用的资源来选择模块。此外，在不约束其他因素的情况下，打分可以帮助确定哪个模块是优选的。
在节点关联性的情况下，也可以使用自描述性表征。例如如下情况，其中将模块a部署在具有偏好等级n的节点a上，而将模块b部署在具有偏好等级m的节点b上。如果n指示比m更高的偏好，则系统将尝试将模块a部署到节点a(如果可用的话)，否则将模块b部署到节点b。
然而，自描述性表征的挑战之一是控制工程师可能实际上不知道给定软件模块的哪个版本最有效地执行某一应用功能，甚至可能不知道该软件模块可以使用什么标准来产生最佳的端到端结果。控制工程师可能只观察到客观结果(例如，什么解决方案“似乎响应性最好。”)。利用软件模块、标准和选项的许多组合，可以使用框架来测试系统模块和替代实现的哪些组合是有效的。
图28描绘了用于自动评价软件模块替代实现的架构。具体地，图28的架构提供用于从应用规范中仿真模块的各种组合并表征结果的框架。来自用户的应用规范和模块清单2820的各种数据被提供给系统。系统可以访问存储在模块映像存储库2810中的所有模块映像。每个模块可以有几种替代实现。
在示例中，在这些实现的各种组合上执行和评价一系列实验。实验可以由表征控制器2830控制，该表征控制器2830将确保各种组合被执行。实验将与标牌器2840一起工作，该编排器2840负责将应用规范和模块清单2820中指定的模块部署到一组仿真器2850上。仿真器2850模拟由在应用规范或模块清单2820中指定的给定替代所定义的硬件(例如，具有一定数量的可用存储器的特定fpga或cpu)。编排器2840将部署应用，互连组件并运行该应用。然后，系统将基于某一标准(例如，端到端等待时间)利用打分2860自动对系统打分，或者用户将基于主观标准(“感觉敏捷”)对该应用打分。最后，系统将推理各种组合，并确定要使用的最佳组合，诸如通过利用基于决策树的方式。
图29图示出继图28中所描绘的示例之后，用于评价软件模块的替代实现的示例方法的流程图2900。在流程图2900中，可选的前提条件包括用于使用应用规范和模块清单信息将应用和模块的配置确定为可以在系统内操作的操作(操作2910)。该前提条件可以作为一次性事件执行或重复执行。
流程图2900的操作继续通过表征控制器定义和执行相应的编排场景(操作2920)，该表征控制器用于在模拟器(例如，根据特定的硬件设置配置的模拟器)中执行具有一个或多个定义的选项的应用模块(操作2930)。利用模拟器，可以执行各种模块和各种模块选项，包括在模拟器或另一个模拟器配置中使用具有一个或多个定义的选项的替代应用模块(操作2940)。替代应用模块的执行可以针对多个各种软件模块和多个选项重复。
流程图2900的操作继续基于定义的性能度量或标准来评价应用模块执行的结果(操作2950)。然后，使用自动化或人为影响的打分过程对用于一个或多个应用模块的执行场景进行打分(操作2960)、排名或进一步评价。基于得分，可以并入或更新应用模块的各种执行场景(操作2970)。
图30a图示出用于使用自描述性可编排软件模块来定义应用的示例方法的流程图3000a。该方法开始于定义哪些软件模块或应用能力被选择并用作应用编排的一部分的操作。这些操作包括模块清单的创建(操作3010a)，其中模块清单用于描述控制系统应用(例如，sdis中的工业控制应用)的模块的经编排执行的各个特性。进一步的模块定义操作还包括：定义用于各种软件模块的操作的各个选项和替代(操作3020a)，以及定义用于各种软件模块的操作的资源标准(操作3030a)。这些操作还包括基于各个软件模块的定义以及各个软件模块内可用的特征的连接要求和条件来定义针对应用的规范(操作3040a)。这样的定义可以包括以上参考图26至图28讨论的各种操作。
流程图3000a继续对各种软件模块进行仿真和评价，诸如在上文参考图29讨论的一个或多个模拟的应用设置中(操作3050a)。仿真的输出可以包括模块的各种实现的优先级或其他属性。根据该评价，可以选择软件模块和用于执行这种软件模块的选项(优先级和其他属性)的特定组合(操作3060a)，并且可以将这些组合部署在经编排的应用设置中(操作3070a)。当结合物理系统的约束和属性时，这样的优先级和选项可以用于通知编排过程。
图30b图示出用于在sdis系统实现中使用自描述性可编排软件模块的示例方法的流程图3000b。在示例中，流程图3000b的操作由编排设备执行，用于在控制系统环境中可操作地耦合到多个执行设备以执行软件模块的编排设备(编排器)。在该配置下，经由至少一个执行设备来执行所选择软件模块在控制系统环境中实现一个或多个控制设备的功能操作。另外，编排设备(编排器)可以用控制系统环境内的编排控制策略对所选则的软件模块的执行进行协调。
流程图3000b从3010b开始，具有创建模块清单和列出所需系统特性的应用规范的可选前提条件。操作3010b可以手动执行或通过自动化/计算机辅助的特征执行。该模块清单由以下过程使用以便定义供软件模块执行控制系统应用的环境。
流程图3000b也在3020b处继续，具有生成用于控制系统应用的应用规范的可选前提条件，该应用规范包括匹配的模块信息和系统特性(包括参数、值等，以用于执行)。例如，用于控制系统应用的应用规范可以定义用于所选择的软件模块的控制参数的值，包括指示软件模块或功能之间的相关连接或关系。
流程图3000b在3030b处继续，以用于标识可用的软件模块，并且在3040b处继续，以用于从模块清单中标识控制系统或控制系统环境的特性。在示例中，标识了能够在控制系统环境中执行特定功能操作的可用软件模块的操作方面。系统的在模块清单中标识出的操作特性可以与以下中的一个或多个有关：通信接口、起始参数、平台要求、依赖性、部署要求或签名。
流程图3000b在3050b处继续，具有基于可用软件模块和系统特性来选择一个或多个匹配的软件模块的操作。例如，该选择可以基于可用软件模块的操作方面与系统的在模块清单中指示的所标识的操作特性之间的匹配。
流程图3000b在3060b处结束，其具有根据应用规范的值和特征来执行控制系统应用的操作，包括相关软件模块的执行。最后，流程图3000b包括3070b处的操作，该操作允许评价相关软件模块的执行(或模拟的执行)，从而允许对清单或应用规范进行进一步的调整和反馈。例如，评价可以包括：使用至少两种不同的硬件架构评价所选择的软件模块在控制系统环境中的执行；以及对利用该至少两种不同硬件架构执行的操作进行效率测量。还可以评价其他类型的执行特性或部署。
在各种示例中，可以使用在图形用户界面中显示的视觉表示来显示和修改控制系统应用。例如，视觉表示可以用于建立一个或多个输入或输出与控制系统应用的关系，包括用于涉及使用一个或多个传感器、执行器或控制器的输入或输出。
传感器总线冗余
传感器总线可以具有冗余，诸如在分布式控制系统中使用多层现场设备冗余。传统工业控制系统将可编程逻辑控制器(plc)用作控制工厂操作的关键要素。单个plc可以对数百个现场设备进行通信和控制，并运行诸如比例积分微分控制器之类的控制算法。由于plc的合并性质，如果plc发生故障，则来自所有下游现场设备的数据将不可用，并且plc上正在执行的控制功能将停止。实现工业控制系统的完全弹性的简单方法是部署完全冗余的环境。然而，两者兼顾是昂贵的，并且带来许多后勤挑战。
在本文描述的系统和方法中，使用了现场设备抽象总线(例如，以太网)，其将物理和功能要求解耦，并且改善了可缩放性并且可以扩展可能的工业架构。
解决制造过程的可靠性和生存能力。现场设备抽象总线使分布式控制环境中的任何有线控制器节点能够与任何有线现场设备进行通信。通过使健康控制节点能够承担发生故障的控制节点的获取和控制责任，该“任意对任意”控制架构可具有改善的生存能力。健康控制节点可以是具有已有控制职责的控制节点，也可以是插入系统以提高生存能力的“过剩(surplus)”控制节点。
扩展数据可用性。在通常是专有的并且已经实现紧密耦合的功能的已有系统中，由于互操作性限制，数据经常不是自由可用的。现场设备抽象总线的实现使得原始现场数据可用于任何经认证的消费者。
先前的解决方案和架构集中于将能力整合到紧密耦合的单个设备中，从而加剧了“单故障点”问题。因此，现场设备数据无论是实体的还是虚拟的都不位于“总线”上。仅主机计算机(plc)能够访问实时现场设备数据，并且如果主机计算机(plc)发生故障，则无法访问下游现场设备数据。
本文描述的系统和方法包括多层现场设备冗余总线，其实现控制器与现场设备之间的“任意对任意”关系。控制器和io的解耦实现了简单的故障转移和冗余。
通过在控制器故障的情况下使任何控制器能够访问任何现场设备来实现改善的系统可靠性和生存能力。降低的系统成本也可能是有益的，诸如通过基于小的增量投资而不是沉重的plc负担来添加新的现场设备。
图31图示出根据示例的基于plc的工业控制系统。
通过与基于可编程逻辑控制(plc)的简化传统部署进行比较，可以理解本文所描述的多层现场设备总线(mlfdb)的优势。实现控制策略的最常见方法是通过使用plc，该plc将控制功能、io接口和网络访问集成到单个设备中，如图31所示。单个plc可以具有高度可扩展性，使得用户可以插入许多io模块以扩展控制系统中的现场设备的数量。尽管plc几十年来一直很好地为工业控制系统市场服务，但是这种方式仍存在一些局限性。首先，如果plc变得无法操作，则无法访问现场设备和控制功能。为了可靠性，工业通过购买两个plc和每个现场设备购买两个来解决此问题。然而，从尺寸、金钱和功率的角度来看，该冗余方法是昂贵的。其次，由于可能需要新的plc，因此对基础设施进行小的增量更改可能需要大量投资。在图31中，每个plc中有y个io模块，其中y是有限数量。y的值可以基于plc供应商/型号，并且例如可以在5到100的范围内。
图32图示出根据示例的多层现场设备总线(mlfdb)。
mlfdb与传统的基于plc的部署的不同之处在于，控制功能与现场设备io完全分离，参见图32。控制功能与io的解耦使控制器与io之间具有“任意对任意”关系，这是提高系统可靠性的关键能力。图32示出了每个控制功能可以访问来自任何已连接的现场设备的数据，同样，每个控制功能可以控制任何已连接的现场设备。该“任意对任意”关系通过内置控制功能的故障转移来提高系统可靠性。例如，假设控制功能1从现场设备2(液位传感器)读取数据，执行计算并调整到现场设备1(泵)的输出值。如果主控控制功能1的设备发生故障，则可以在能够访问现场设备总线的另一台设备上执行控制功能1的过程。这是可能的，因为现场设备在总线上仍是可访问的。
图33图示出根据示例的io转换器功能。
现场设备总线包括io转换器。io转换器是可单独寻址的设备，其将现场设备io转换为现场设备总线的协议。如图32所示，存在直接附接到每个现场设备的物理小型、高可靠性的io转换器。io转换器的数量可以在1到n的范围内，其中n受操作的物理环境约束。在图33中以堆叠视图示出了io转换器功能的高级视图。
io转换器负责以下功能：
至现场设备的电气接口：从io转换器到现场设备的接口，可以是4-20ma模拟输入/模拟输出、24vdc数字io、串行接口或基于以太网的协议中的任何一种。该接口的该设计实现可以确定io转换器的sku。例如，io转换器sku1可以是4-20ma模拟输出或模拟输入。sku2可以是用于大电流继电器的离散输出。
现场设备协议：该功能将命令、控制和数据编码/解码为与下游现场设备通信所需的适当格式。例如，假设下游现场设备是modbus从设备。该功能将对符合modbus协议的read请求进行编码，并将该请求发送到现场设备。
抽象：抽象功能将特定于现场设备的命令和数据转换为人类可读的格式(由数据模型定义)。例如，假设io转换器连接到通过4-20ma模拟接口进行通信的泵，并且控制系统希望将流速设置为10gpm。该功能将把10gpm请求转换成至对应的毫安值的电流设定点。相反，当数据以特定于现场设备的格式来自现场设备时。
信息建模：该函数模型根据由系统操作员定义的模式(例如，haystack)对数据建模。
现场设备总线协议层可以符合用于传输建模数据的工业协议。例如，数据分发服务(dds)、qpcua或profinet协议。
至现场设备总线的电气接口。电气接口可以包括以太网、pci、profinet、专有总线技术等。
供应功能：层是检测下游现场设备的身份的发现层。检测服务可以被内置在本机现场设备协议(例如，hart)中，或者可能需要将其添加为附加发现服务。无论哪一种方式，供应层都代表下游连接的现场设备的身份。
操作模式和资源状态层负责向编排系统报告健康和状态。健康和状态数据包括本地资源利用、工作负荷状态、唯一模块属性和操作模式。
本地资源利用的示例可以是用于可靠操作的cpu加载、存储器利用、存储、页面丢失、错误等。
工作负荷状态将捕获正在运行的进程的状态和健康，崩溃的进程可以触发警报，编排系统可以通过该警报来启动故障转移条件。
唯一模块属性由io转换器的唯一标识符(可以是基于硬件的)、ip地址、mac地址或证书等工件组成。
操作模式是指冗余系统中的io转换器角色。例如，可以将io转换器置于热待机模式或置于主要模式。另外，可以将io转换器置于将自身与现场设备电隔离的模式下，诸如使对等io转换器物理连接到现场设备。
代理：驻留在io转换器上的代理为各种io转换器功能安排配置参数。
图32或图33所示的现场设备总线包括不是特定于总线技术，并且可以用许多不同的技术实例化。例如，可以根据基于以太网的设备在工业控制系统空间中增加的普遍性而使用以太网。基于以太网的现场设备抽象总线的优点是增加了现场设备对更广泛系统的可访问性。然而，为了维持可靠和确定性的能力，基于以太网的现场设备抽象总线可能需要集成时间敏感的联网(tsn)。tsn的集成可以使基于以太网的现场设备抽象总线能够匹配基于profinet或基于ethercat的系统的可靠性和及时性。
图34图示出根据示例的io转换器冗余。
多层冗余可用于解决直接连接到现场设备的io转换器发生故障的情况。为了缓解该情况，如图34所示，将多个io转换器添加到现场设备总线，并将其物理地连接到单个现场设备(采用多点配置)。每个io转换器具有1..x个开关输出，其中一次只能有源驱动1个输出。这实现了由io转换器模式控制器控制的io转换器冗余。编排系统可以监视相应地切换输出打开/关闭的每个io转换器的健康和状态。io转换器模式控制器可以对哪个io转换器控制哪个现场设备进行变更。
图35a-图35b图示出根据示例的用于实现mlfdb的方法的流程图3500a-3500b。
流程图3500a包括用于在io转换器处接收来自现场设备(例如传感器)的数据的操作3510。流程图3500a包括用于根据现场设备总线协议来转换来自现场设备的数据的操作3520。流程图3500a包括用于将转换后的数据发送到现场设备抽象总线的操作3530。流程图3500a包括用于经由现场设备抽象总线接收来自控制设备的控制信号的操作3540。流程图3500a包括用于基于控制信号将电信号发送到现场设备的操作3550。
流程图3500b包括用于经由多个对应的io转换器在传感器总线处从多个现场设备(例如，传感器)接收数据的操作3560。流程图3500b包括用于将数据发送到一个或多个控制功能的操作3562。流程图3500b包括用于基于该数据从一个或多个控制功能接收一个或多个控制信号的操作3564。流程图3500b包括用于将一个或多个控制信号发送到多个io转换器中的相应io转换器的操作3566。流程图3500b包括用于从io转换器模式控制器接收信息的可选操作3568。流程图3500b包括用于促进根据从io转换器模式控制器接收到的信息将io转换器分配给现场设备的可选操作3570。
工业系统中的动态警报
工业控制系统在监督模式下严重依赖警报作为机器操作的保护。在许多情况下，这些警报是基于人类的知识和对系统的理解而创建的。结果，警报不是最佳的。典型的系统将由控制工程师使用对被认为是系统的次优或有害的所有状况的许多警报来启用。例如，针对低于或高于某个阈值的电压值创建警报。通常由于以下3个原因之一在控制系统中创建警报：
安全(人员和环境)
设备完整性
质量控制
然而，警报管理中的问题之一是这些警报是由人产生的，并且往往易于对可能不重要的事物进行警报。更糟糕的是，警报通常是冗余的，因为同一物理事件可能会生成多个警报；这通常称为警报泛滥。
当前的警报系统严重依赖于人的产生和输入。结果，他们倾向于遭受过度分派。这在在工作故障情况下、大量警报被产生并且通常分散人们注意力的警报泛滥时容易看到。
已有的解决方案倾向于过度产生警报，这是危险的并且可能导致警报疲劳。该警报产生是用于检测在控制系统中存在问题的情况的假肯定的过度生成的结果。如果警报导致大量事件，则还可能使设计为将这些事件用于其他应用(例如异常检测)的分析法过度复杂化。
本文所描述的系统和方法使用智能机器学习方式来管理警报。
本文描述的系统和方法可以：
表征数据以便检测可能触发警报的异常；
使用数据相似度或通用因果关系对警报进行聚类，使得将它们作为一个捆包呈现，以便应对警报泛滥和疲劳；或者
了解人对警报的响应，以便将来使这些动作自动化。
图36图示出根据示例的具有产生的警报的过程的示例。
在工业系统中，数据通常由不同的模块和传感器生成。该数据是警报产生的基础。在其最基本的形式中，基于诸如传感器数据超过阈值之类的条件来生成警报。例如，如果物理过程连接到功率计，则控制工程师可以知道，如果设备(集体地)消耗的功率大于电路所能承受的功率，则可以发出警报来人为干预。警报可以经历多个级别的升级。例如，最初，发出警报，但是如果功耗继续上升，则产生附加的警报，并且从系统关闭电源。后一种情况可能是不希望的，因为它可能招致与生产率和工时损失相关联的成本，以使过程恢复到操作状态。
警报可以具有级联作用。例如，当第一个过程关闭时，沿工厂生产线的下一个过程将停止，这可能进而引发一个或多个警报。操作员突然可能发现自己身处警报泛滥。确定他们应该响应哪个警报以及如何响应通常可能很累人并且需要进一步的分析和专业知识。
本文描述的系统和方法使用机器学习来分派警报、聚类警报或提出响应动作。
图36示出具有由系统生成的警报的示例的物理过程。
这些警报可以包括以下数据字段中的一个或多个：
警报类型
生成警报的物理过程
警报关键性
时间戳
警报的可能的标志或原因
被标记为警报接收者的(多个)用户
希望重置或解决警报的可能动作
可以将数据发送到中央位置，然后可以将该数据路由到hmi屏幕、用户的移动设备或用于分析和存档的存储库。
在本文描述的系统和方法中，用户可以创建警报。然后可以保存和分析这些警报配置。基于该数据、上下文和警报配置，可以向用户呈现附加的警报建议。例如，如果为电表创建了带有元数据的警报，该元数据指示这些电表在工厂车间。
使用工厂的元数据(和信息模型)来分析其他设备与这些创建的警报及其对应的物理设备的相似度。此外，由这些设备生成的数据的类型和可以触发警报的流将馈送到相似度模块中。
图37图示出根据示例的动态智能警报。
图37的系统包括可以称为数据签名管理器的数据剖析器。该模块可以使用机器学习来确定流相似度。这些相似度中的一些可以基于单独的流或作为流之间的相关性。例如，可以与从相似的物理过程产生的另一液位传感器来确定液位传感器流。例如，可以基于以下各相认为物理过程是相似的：
物理过程的元数据；
与同一物理过程相关联的流的数量和类型；
同一物理过程的不同流之间的交叉相关性；或者
来自不同过程的流的类型和频率的相似度。
例如，当第一物理过程具有20个流并且其中3个是液位、2个是液体流量，并且第二物理过程具有21个流并且3个是液位、2个是液体流量时，这2个流可以在相似度上具有高排名(相同数量的液位和液体流量，仅相差1个流)。
数据签名管理器将其输出馈送到动态智能警报系统。动态智能警报系统充当分类单元，用于标识需要基于相似系统的已有警报来调整其警报的潜在过程。
动态智能警报系统可以以下3个组件组成：
警报生成器：在该模块中，默认预先加载或创建了一些预警报。这些可以是由人类明确创建的，也可以是基于要求创建的。例如，某一电路上的功率消耗不应超过某一阈值。该模块负责生成、编辑或删除警报。该模块使用数据相似度的输出以便决定是创建警报还是建议警报。它可以为特定警报的需要创建得分。在得分非常高的情况下，警报生成器可以自动创建警报。然而，如果得分是中等的，则该模块可以例如在创建这样的警报之前，请求人类操作员/专家进行输入。警报生成器的工作也是将警报标记为相似、相关或独立。当产生多个警报时，下一个模块将使用此标签。
警报管理/聚类：该模块跟踪警报之间的关联。它可以使用由警报生成器创建的标签。它也可以通过监视来自实际警报的数据来扩展标签。警报管理可以监视不同的警报输出，以便检测相关性或事件序列。它可以对数据运行这两种类型的分析法。
相关性可以确定2个事件高度相关，并且可以将它们聚类在一起。例如，特定的物理过程可以具有5个不同的警报，以便针对不同的事件发出警报。但是，如果系统因严重故障而停机，则可能同时或在短时间内激活所有警报。然后，这些事件被高度相关，并且可以被聚类以最小化警报泛滥和疲劳。模块还可以使用警报的元数据及其所覆盖的系统，以便创建有意义的理由来对组件进行聚类。使用与上述相同的示例，这5个不同的警报可以具有与它们相关联的物理过程的元数据。因此，这5个可以用“区域3西2楼的液位储罐处理”折叠。另外，聚类可以使用警报本身中的数据进行有意义的解释。
图36示出警报可能包含的内容的示例。可以聚合数据，并且结果可以显示为“级别：严重，原因：功率太高”。该聚类可以使用来自自然语言处理(nlp)的技术以用于创建这些有意义的描述。许多该描述可以是人为产生的，并且在描述相同类型的故障时可能会稍有不同，并且nlp可用于调整或分组稍有不同的故障。在示例中，如果警报x注意到其将转发给系统y，然后系统y导致用户选择重置，那么也可能只在警报x处重置。刚开始，图37的系统可以缓慢进行，表明在x之后重置，然后随着时间的推移，无需询问就重置。
该模块还可以将警报序列建模为状态机。例如，模块可以注意到，当过程1失败时，过程2中报告的失败概率非常高。类似的技术可以用于预测性维护，其中使用状态机对一系列事件进行建模，并且将概率分派表示过渡的边缘。这允许算法预测如果系统落在状态s1上并且s1和s2之间的过渡具有高概率边缘，则可能发生状态s2。该特征可以允许模块预测将要触发另一组警报，并且可以潜在地提前通知用户。可以在事件发生之前或之后显示警报之间的关系。
警报输出管理器：该模块用于使系统进入自主操作。最初，该模块可以没有策略或只有一些简单的转录策略。然后，当警报被产生和处理时，它可以监视用户动作。如果一组警报倾向于被忽略，则该模块可以随着时间的推移学习到这些警报是没有意义的，并且可以被赋予低优先级甚至被删除。在示例中，如果没有人的同意，删除可以不会发生。另外，模块可以监视和记录其他事件。例如，当发出警报时，人类操作员可以尝试几个动作方案。动作方案可以包括：变更参数的配置、重置模块、重启系统的一部分等。例如，可以通过使用警报输出管理器来进一步表征故障的特定特征、或者确定确实需要重启系统、或者可以使用简单的模块重置，来避免该序列。另外，当系统的置信度增加时，它可以独自采取这些动作。在示例中，最初，选项可以作为推荐呈现给人类操作员。
图38图示出根据示例的用于动态警报控制的方法的流程图。流程图3800包括用于保存与工业控制系统的多个警报有关的信息的操作3810。流程图3800包括用于从信息中分析用于多个警报的数据、上下文和警报配置的操作3820。流程图3800包括用于建议对多个警报中的一个或多个警报的更改或建议新警报的警报3830。流程图3800可以包括用于从信息中确定警报流相似度的操作3840。流程图3800可以包括用于检测两个或更多个警报处的警报事件的操作3850。流程图3800可以包括用于阻止这两个或多个警报发出的操作3860。流程图3800可以包括用于为被阻止发出的两个或多个警报生成聚类的警报的操作3870。
用于利用闭环控制操作的学习的自主集成方法
自主学习方法的集成在工业界的实际有界实现中持续增长，其中机器人技术和自动驾驶空间取得了很大进展。随着it-ot融合继续实现并使更多的模块化系统灵活性成为可能，这些开发技术和方法的前瞻性自主应用将进入更广阔的连续和离散制造业。自主标识对任务关键型操作具有经验证价值的新模型的能力、以及以置信度自主部署经验证的能力和“闭环”的能力将为符合iec61131-3，iec-61499和更高级别的isa(l1-l3)控制系统领域的制造企业带来新级别的效率、成本节省和底线价值。
传统闭环控制系统与自主学习技术的集成要求创建新的弹性解决方案架构方法以支持自主工作流。这些方法还将固有地产生新的自主开发的闭环控制解决方案架构建议，其将需要针对在连续和离散制造操作两者的定义的参考架构边界内适合的可行实现进行评估。这种自动“闭环”的自主系统可以支持针对用于可行的任务关键型系统部署的安全、质量、约束标识、实施可行性、值打分、自动化监视以及系统管理集成的实时策略评估。自主性可以扩展到纯软件集成之外，并且可以与端到端系统部署的所有方面集成，包括跨计算、存储和联网资产的硬件选择。对于创建的任何特定的新控制应用，可以需要跨多个子系统域的实时协调和验证，以确保用于自主部署的闭环解决方案的安全且有界的操作。
本文提出了一种顺序严格的策略框架和一系列方法，以用于通过以下8个过程来管理任务关键型环境中新的闭环工作负荷的自主创建：
新算法相对于过程的质量和灵敏度评估；
操作约束边界的自动化建立；
新算法相对于已有过程的自动化安全评估；
对于更广泛的过程的自动化价值评估；
对于在控制环境中的部署可行性的自动化系统评估；
新应用控制策略的物理部署和监视；
集成到生命周期管理系统中；以及
集成到报废处理中。
这8个步骤过程的操作顺序可以更改。例如，安全评估可以在价值评估之后。
典型的自动化系统尽管在控制策略的实现方面非常先进，但是固有地被锁定在通常不存在这种系统弹性的传统系统部署中。新系统可以具有反映it系统中发现的系统进步的新级别的灵活性和弹性，并且当前it或的ot系统目前都没有拥有这种级别的自主智能。
通常，在分布式控制系统设计空间中实现的先前解决方案不允许新控制策略的任何级别的自主创建，而在没有高度工程监督的情况下进行后续实现和调试(闭环)。此外，目前的控制策略设计不是自主的，并且需要高度的工程设计。控制实现也是高度资源密集的工程设计活动。其中回路为闭合并且算法被调整的控制调试活动也是手动且高度工程设计的过程。目前自主地完成这些任务中的任何一个都是在实践中闻所未闻的。
先前的解决方案可能没有利用创建对相对于已有过程新创建的算法的自动化一般安全评估的能力。先前的解决方案可能没有利用创建对相对于已有过程的新算法的自动化质量和灵敏度评估的能力。先前的解决方案可能没有利用创建操作约束边界的自动化建立的能力。先前的解决方案可能没有利用创建针对向控制环境中的部署可行性的自动化系统评估的能力。先前的解决方案可能没有利用创建针对基于可用数据的更广泛过程的自动化价值评估的能力。
先前的解决方案可能没有利用创建新控制应用的自动化物理部署和监视的能力。先前的解决方案可能没有利用创建向已有的标准化生命周期管理系统的自动化集成的能力。先前的解决方案可能已被锁定在动态工作负荷修改和可移植性是不可能的应用和设备特定的实现中。先前的解决方案可以与硬件和软件紧密耦合。在大多数情况下，先前的解决方案可能会过于昂贵。先前的解决方案可能要求具有自定义中断管理的自定义硬件。先前的解决方案可能不包括动态发现、模拟和优化，其将价值事件预测为用于决策树的规则集的一部分。
这里提出了顺序严格的策略框架和一系列方法，以用于通过这8个步骤(可以按以下次序进行，也可以按其他次序进行，或者具有一些在同一时间段或重叠发生的步骤)来管理任务关键型环境中新的闭环工作负荷的自主创建：
新算法相对于过程的质量和灵敏度评估；
操作约束边界的自动化建立；
新算法相对于已有过程的自动化安全评估；
对于更广泛的过程的自动化价值评估；
对于在控制环境中的部署可行性的自动化系统评估；
新应用控制策略的物理部署和监视；
集成到生命周期管理系统中；以及
集成到报废处理中。
本文描述的系统和技术提供分布式应用控制策略级别的能力，用于：
在控制之下实现整体学习系统操作能够与已有控制系统分层结构的集成。
在控制之下实现用于相对于已有操作过程的新算法的自动化安全评估。
在控制之下实现相对于已有物理过程的新算法的质量和灵敏度评估。
在控制之下实现针对系统的操作约束边界的自动化建立。
实现对针对控制环境自主创建的应用的部署可行性的自动化系统评估。
在控制之下实现针对更广泛的过程的自动化价值评估，以确保自主创建的控制算法的积极经济影响。
实现用于自主地物理上部署新自主创建的控制应用并为新自主创建的控制应用创建新的监视的能力。
实现向标准生命周期管理系统的自主集成。
实现通过连续的roi监视向报废处理的集成。
继续进步并利用更低成本的商品硬件和软件，以在控制策略级别上实现更好的系统性能。
使许多维护任务能够自主发生，其中在自动化配置中设计了自主功能。
图39图示出自主控制-学习集成流程图。
这里提出了顺序严格的策略框架和一系列方法，以用于通过这8个步骤(可以按以下次序进行，也可以按其他次序进行，或者具有一些在同一时间段或重叠发生的步骤)来管理任务关键型环境中新的闭环工作负荷的自主创建：
新算法相对于过程的质量和灵敏度评估；
操作约束边界的自动化建立；
新算法相对于已有过程的自动化安全评估；
对于更广泛的过程的自动化价值评估；
对于在控制环境中的部署可行性的自动化系统评估；
新应用控制策略的物理部署和监视；
集成到生命周期管理系统中；以及
集成到报废处理中。
下面示出了这八个顺序过程的相互作用，并且在图39中更详细地描述了每个过程，其具有作为支持连续24/7任务关键型操作的基础的迭代反馈分析。
a.新学习算法的创建
该过程可以从创建新的学习算法开始。所采用的自主过程将具有对与系统资源、物理过程和控制系统参数相关联的所有数据的系统范围访问，包括基本isa级别1控制(iec61131-3/iec61499-3功能块、二进制、梯形逻辑、pid等)、约束和监督控制(l2/l3)、多变量模型预测控制(l3)、生产调度(l3)和计划系统访问(企业)。学习系统范围可以包括与财务和会计、合同管理以及一般企业或供应链操作相关联的非常规系统访问。虽然利用显著相关性创建的算法可以涵盖广泛的算法家族，包括简单的面向小数据的数学解法(求和、除法、乘法、pid、统计等)、基于第一原理的自主模型开发、基于经验的自主模型开发、大数据分析法、机器学习和深度学习算法等，但本公开未描述可以产生的算法的完整环境。从数据科学的观点来看，这种算法可以是开放式的。
随着分析从步骤a依次转移到步骤i，将自主创建并执行通过和失败测试，以评估和验证所创建的新的自主学习和控制循环。采用迭代过程来支持实时的通过/失败分析。某些步骤可能不按顺序执行、同时执行等。
b.质量和灵敏度评估
一旦在步骤a中自主发现了显著性模型，就调用步骤b以形成对所创建算法的初始质量和灵敏度评估。自主质量和灵敏度评估依赖于过程的最新实时模拟的过程模型(数字孪生)。模拟的过程范围可以是整个过程的子集，其可以包括与阀门或泵一样小的物品，或覆盖受控制的完整过程单元(炼厂原油单元、反应器或工厂的更广阔区域)。该一般质量和灵敏度评估采用在步骤a中创建的模型，并将其叠加于分布式控制系统中主动使用的模拟的物理过程和控制算法上。然后，质量和灵敏度评估通过为新模型生成输入信号(prbs，施罗德波等)来执行每个独立的过程变量，并且针对模拟的过程和系统中部署的主动控制策略来跟踪随着时间的推移对相关过程变量的影响。对于考虑新模型对模拟的过程操作的灵敏度的质量评估概要文件，过程输出结果既是绝对的又是统计地测量的。
表1对质量和灵敏度的架构子系统评估
表2质量和灵敏度评价
如果测试通过，则模型评价移至步骤c。如果测试失败，则将结果发回学习系统进行重新评价。
c.约束边界标识
步骤b的结果用于为所创建的新模型设置约束边界，该约束边界包含并实施针对所创建的新算法的过程范围的操作安全、质量和灵敏度标准。然后，通过模拟(例如，添加噪声、扰动、查看系统如何使用新模型进行反应)运行所标识的新约束边界，并将结果与新生成的约束概要文件进行比较。
表3用于约束边界标识的架构子系统评价
表4过程约束边界标识
如果测试通过了过程模拟以及相关联的已有控制模型和新控制模型的评价，则允许评价移至步骤d。如果测试未能通过上文描述的标准中的任意标准，则将结果发回学习系统以进行重新评价。
d.安全评估
一旦在步骤c中标识出一组新的约束，就调用步骤d以形成对所创建算法的初始安全评估。步骤d涵盖了新学习算法对用于使用该新学习算法进行闭环操作的物理过程的相对影响的安全评估。这里，基于模型创建期间在步骤a中建立的统计质量，通过将噪声引入模型i/o，从而在一定条件范围内评价模型质量。
自主安全评估依赖于过程的最新实时模拟的过程模型(数字孪生)。模拟的过程范围可以是整个过程的子集，其可以包括与阀门或泵一样小的物品，或覆盖受控制的完整过程单元(炼厂原油单元、反应器或工厂的更广阔区域)。该一般安全评估采用在步骤a中创建的模型，并将其叠加于模拟的物理过程和在分布式控制系统中主动使用的控制算法上，并叠加步骤c中所描述的控制系统标识的新约束。然后，安全评估通过为新模型生成输入信号(prbs，施罗德波等)来执行每个独立的过程变量，并且针对模拟的过程、系统中部署的新约束和主动控制策略跟踪随着时间的推移对相关过程变量的影响。然后将结果与针对用于确定通过/失败得分的过程建立的安全度量进行比较。
存在可使用且在这里未被涵盖的广泛范围的潜在安全检查，但其通常可表现为对于流量、压力、温度、rpm或针对通常安全操作可能未被超过的其它关键变量的关键过程约束。该分析不与经认证的功能上安全的系统相混淆，尽管对与这些系统相关联的变量的影响被认为在一般安全分析的范围内并且实践中可以包括在过程和控制模拟中。表5针对安全的架构子系统评价
表6一般过程安全评价(未经认证的fusa)
针对用于受控制设备或过程的安全概要文件来测量结果。如果算法通过了针对制造操作的设备或过程流程的所有安全检查，则允许验证过程移至步骤e。如果任何安全检查失败，则将结果返回到自主学习算法块，以重新评估和重新创建显著性算法。
e.价值评估
价值评估用于自主地评价新模型对本地过程段以及更广泛的端到端制造过程的影响。利用针对模拟的过程(数字孪生)和控制系统标识的边界约束，通过使用新的控制策略重放历史数字孪生模拟结果来自动评估对闭环性能的上下文内的新学习算法对企业底线的影响的评价。使用各种价值标准将结果与基准性能进行比较。示例如下表7所示。
表7示例价值评估标准
如果价值评估达到操作指定的指定rqi和npv标准，则测试通过，评价进入步骤f。如果测试失败，则将结果发回学习系统以进行进一步评价。
f.部署可行性
部署可行性是根据系统部署新工作负荷并将算法集成到分布式控制系统的已有控制结构中的能力来度量的。在该过程中完成对以下领域的严格实时评估：
表8部署可行性子系统评价
如果通过了部署测试，则通过实际部署到数字孪生模拟系统上来测试部署，该数字孪生模拟系统中，利用操作自动调度训练。
自动化的训练模拟器部署和进程调度：
i.生成的新控制循环的自动化训练文档，并将其发送到用于审查的操作。
ii.训练计划是根据操作建立和完成的。
g.物理部署和监视
在使用针对控制系统标识的新约束在步骤f中测试了物理部署和监视的情况下，通过操作进行的训练和退出将在准备用于部署的新控制策略下完成。物理实现按系统编排器的管理进行，其中指定了新功能块的输入和输出配置以及对旧功能块的修改。用于可行的自主部署的步骤如下：
在线部署到操作：
1.程序上，所有控制可被自动放弃到其最低允许的自主稳定循环配置，如用于新控制系统特征的自主系统实现和调试的操作所预先指定的。
2.利用可用的系统资源(计算、存储、联网等)完成在定义的系统约束和监视配置内的(多个)新的控制和学习模型的物理部署。
3.自动化调试发生在新的循环自动开始以“暖模式”运行的情况下，其中将实时i/o馈入新的控制循环，并在指定的时间段内分析自变量的新控制动作以验证行为符合预期。
4.一旦完成在线验证测试，就为新算法封闭循环，并且将新输出写入下游设定点，该设定点利用发送到操作的通知来驱动任务关键型过程。
如果针对上文描述的所有4个步骤的自主部署都成功，则系统继续进行以便自动向生命周期服务注册。如果系统的自主物理部署在上文描述的4个步骤中的任何一个步骤中失败，则将系统返回到其先前的配置，将结果发送回学习系统，并通知操作。
h.生命周期集成
自动注册由为正常操作部署的系统的新控制和学习循环组成。
l.生成、测试和部署自动化脚本，从而将新的控制应用注册到生命周期管理系统。
2.反馈循环针对图39所示的质量、约束、安全、价值、部署和生命周期性能的自动化度量连续监视新控制应用。
所监视的度量中的任何一个度量的降级都可能将当前正在运行的控制策略发回控制学习评估块，或者导致限制规范的更改，或者更改调整参数，更改部署等。
i.报废
利用反馈(参见图39)，针对经济价值评估的度量的连续检查可以驱动企业的操作价值的自动化评估。价值下降到低于定义的标准导致触发报废过程。
虽然可以自动进行报废处理，但是将需要用于恢复到手动审核的选项，并且可能会导致自动停用，或者需要取决于自动化复杂性的手动移除。
图40图示出根据示例的用于管理用于工业控制系统的新算法的自主创建的方法的流程图。流程图4000包括用于管理新闭环工作负荷算法的自主创建的操作4010。流程图4000包括用于执行新算法相对于过程的质量和灵敏度评估的操作4020。流程图4000包括用于自主建立操作约束边界的操作4030。流程图4000包括用于自主评估新算法相对于已有过程的安全性的操作4040。流程图4000包括用于自主评估用于该更广泛过程的值的操作4050。流程图4000包括用于自主评估系统在控制环境中的部署可行性的操作4060。流程图4000包括用于物理部署并监视新应用控制策略的操作4070。流程图4000包括用于将新算法集成到生命周期管理系统中的操作4080。流程图4000包括用于将新算法集成到报废处理中的操作4090。
分布式控制环境中的可缩放边缘计算
当前的解决方案要求终端用户估计所需的计算量，并将添加附加计算能力以便对部署进行将来验证。这些方式浪费金钱、电能和热能。这也冒着在实际需要计算之前将过度供应的计算变为旧技术的风险。
本文讨论的技术允许由理解工业系统的控制策略的cpu性能需求的集中式编排系统在工业控制系统的边缘控制节点中的高性能cpu从初始休眠或非活动状态激活。由于每个边缘控制节点最初都是作为低成本、低性能的设备出售的，因此初始客户投资较低。仅购买和供应所需的计算(正确大小的计算)，这优化了货币投资、热覆盖区和电能消耗。该解决方案在控制系统中提供了可扩展的计算覆盖区。
图41图示出工业控制系统(ics)环形拓扑网络4102。
工业控制系统通常由可编程逻辑控制器4104、远程io(rio)(例如4106)和现场设备(例如4108)组成。典型的部署可以包括由plc4104控制的远程io单元的环。通常将io和现场计算锁定在plc4104中(例如，在图41中)。
图42图示出边缘控制拓扑网络。边缘控制拓扑网络包括(例如，如以上针对编排920所描述的)编排服务器4202、桥4204、多个边缘控制节点(例如，ecn4206)和一个或多个现场设备(例如，4208)。编排服务器4202用于在ecn设备(例如4206)处供应、控制或编排动作，该ecn设备例如在环形网络中相互连接，并经由桥4204连接到编排服务器4202)。
sdis改善系统功能的一种方式是跨ics分布控制功能。编排服务器4202可用于控制边缘控制节点4206，其包括在单个设备上执行io和计算两者的选项，并使用编排服务将工作负荷分配给最佳可用资源。
通常，边缘控制节点(ecn)的环可部署在受热限制的环境中，例如气流为零或温度不经调节的机柜。在示例中，单个机柜中可能有多达96个io，这意味着多达96个ecn。这可能禁止每个ecn既包括io又包括高性能计算，因为高性能计算设备将产生过多的热量并将环境温度升高到ecn的安全操作水平之上。另外，当控制系统的计算需求不高时，可能不需要在每个ecn处都具有高性能处理器。因此，本文所描述的系统和技术提供了仅安装执行控制策略所需的计算资源并且不超过成本和功率目标、同时仍允许每个ecn中的变更的能力。因此，在示例中，并非每个ecn都具有高性能处理器或高控制能力。
图43图示出边缘控制节点(ecn)框图4302。在示例中，以下技术通过引入图43所示的计算可缩放ecn来提供计算问题的“正确大小”供应。
ecn4302的主要成分可以是片上系统4304，其具有较高性能的计算(例如，cpu)4306和用于低性能计算的微处理器(mcu)4308。mcu4308可用于将来自io子系统4312的io数据转换为网络组件4310，诸如基于以太网tsn的中间件，诸如opcua发布/订阅或dbs。ecn4302可以在高性能cpu4306处于非活动状态的情况下交付给客户。例如，高性能cpu4306可以无法在非活动状态下被访问，诸如直到从例如编排器向高性能cpu4306发送特殊的“激活信号”为止(例如，编排器可以向发送被发送到mcu4308的信号来激活cpu4306)。
ecn4302可以最初安装为低成本、低功率设备，以用于使用mcu4308进行io转换。例如，最初禁用了高性能cpu4306，并且最初，ecn4302包括被激活的soc4304和io子系统4312，而没有高控制能力。在示例中，高性能处理器4306可能是非活动的，ecn4302最初仅允许io转换。
图44图示出基于ecn的环形拓扑图。图44示出了可缩放计算ecn如何适配到经典环形拓扑。图44还示出了部署的初始状态，其中所有高性能cpu被禁用。如图44所示，每个ecn都具有将io转换为数据总线标准的能力，但没有执行控制功能的真实能力。
在示例中，在部署之后，编排服务器4202可以确定需要多少个高性能cpu，然后使用特定ecn处的相应mcu发送代码以激活一个或多个cpu。编排服务器4202可以提供成本/收益分析，作为由编排服务器4202执行的调度功能的一部分。在示例中，可以例如根据诸如月度、年度许可等之类的调度安排来收取费用以激活cpu4306。可根据需要(例如，由编排器或用户确定)激活或去激活cpu4306。有限许可可以比完全部署便宜。在另一示例中，一旦被激活，cpu4306就可以无限期地保持激活状态(例如，通过一次性付费的永久性地激活)。
在示例中，不激活cpu4306可以减少热输出。这可以与任何费用调度安排分开控制。例如，一旦被激活，cpu4306可以被去激活或被转移至低功率状态以节省热输出(即使在cpu4306被永久激活的示例中)。cpu4306可以在高功率状态下执行控制指令，并且在执行完成时转移至低功率状态。
在示例中，激活码可以是发送到mcu4308的特殊分组。可以由mcu4308评价激活码的有效性，包括确定该码能用多长时间等。mcu4308可以直接向cpu发送激活信号(例如，在从编排器接收到信号之后)。
当从非活动状态激活cpu4306时，mcu4308可以打开功率轨，引导cpu4306，下载最新固件等。在示例中，cpu4306可以具有低或高功率模式，该模式可以被激活或去激活而不是关闭或打开cpu4306。在将cpu4306置于低功率状态而不是关闭电源以减小热输出的情况下(诸如在可能需要快速激活cpu4306时)，该示例可能有用。
在示例中，可以通过提供编排器4202从cpu制造商获得的加密令牌来实现低功率状态。这些令牌可以经由mcu4308发送到cpu4306。例如，可以使用只有cpu制造商和cpu4306知道的密钥(例如，在制造时被烧入cpu4306的密钥)来对令牌进行签名，从而允许对每个令牌进行验证。每个令牌可以是唯一的，从而允许cpu4306运行一段时间。
在另一个示例中，令牌由mcu4308使用制造商和mcu4308已知的机密进行认证。例如，只要将mcu4308和cpu4306一起制造在soc的单个封装中。该示例可以防止通过唤醒cpu4306来验证令牌而创建的拒绝服务攻击。
图45图示出通过基于ecn的环形拓扑的数据流。在示例中，编排系统4202分析控制策略以了解需要多少计算来满足控制策略的计算需求。一旦编排系统生成了计算要求，终端用户就可以从ecn供应商处购买所需量的高性能cpu激活码。编排系统4202将已认证的激活码发送到ecn阵列中的指定ecn，该指定ecn启用计算资源。该流程在图45中示出。
启用计算的过程不必是一次性事件。随着控制策略的复杂性增加和计算需求增加，终端用户可以继续购买并激活更多的计算资源(或在不需要时去激活cpu资源)。例如，编排器可以将去激活信号发送到ecn以便去激活该ecn处的cpu。ecn供应商可以实现时间服务模型，其中终端用户每月或每年购买激活许可证。该模型还允许终端用户让激活码到期，从而允许一些计算资源返回低功率休眠状态，从而节省重复费用。
图46a图示出根据示例的用于激活(例如ecn的)cpu的方法的流程图4600a。流程图4600a包括用于在编排服务器处确定工业控制系统(例如环形部署)中的边缘控制节点的计算要求的操作4610a。流程图4600a包括用于接收激活一个或多个边缘控制节点的cpu或确定一个或多个cpu需要激活的指示的操作4620a。流程图4600a包括用于将经认证的激活码发送到具有要激活的cpu的边缘控制节点的操作4630a。在示例中，可以由编排服务器执行操作4610a-4630a(上方)，并且可以由ecn执行操作4640a-4670a(下方)。使用流程图4600a的方法可以包括执行操作4610a-4630a或4640a-4670a或两者。
流程图4600a包括用于在边缘控制节点处接收经认证的激活码的操作4640a。流程图4600a包括用于在边缘控制节点处认证该码的操作4650a。流程图4600a包括用于使用mcu(低性能处理器)激活边缘控制节点的cpu的操作4660a。流程图4600a包括用于在边缘控制节点处从编排服务器接收更新以便去激活cpu或将cpu置于低功率状态的可选操作4670a。在示例中，ecn可以是工业控制系统的环形网络的一部分。
图46b图示出根据示例的用于激活cpu的方法的流程图4600b。流程图4600b的操作可以由编排服务器执行。编排服务器可以诸如经由桥设备通信地耦合到边缘控制节点的环形网络。
流程图4600b包括用于确定工业控制系统中的边缘控制节点的计算要求的可选操作4610b。在示例中，边缘控制节点可以是环形拓扑网络中的节点，其中桥设备将网络连接到编排服务器。
流程图4600b包括用于通过将编排服务器连接到边缘控制节点的桥来接收数据的操作4620b。可以在边缘控制节点的微控制器(mcu)处从在io子系统处生成的数据转换为io数据。转换可以是由边缘控制节点(也可以包括mcu)的片上系统的以太网交换机发送的分组。在另一示例中，由mcu转换的数据可以是由mcu本身生成的数据，诸如现场设备或边缘控制节点的功率状态。
流程图4600b包括用于将经认证的激活码发送到边缘控制节点来激活边缘控制节点的最初处于非激活状态的cpu的操作4630b。在示例中，经认证的激活码在cpu被激活之前由mcu进行认证。
流程图4600b包括用于将处理指令发送到cpu以用于执行的操作4640b。
流程图4600b包括用于将去激活码发送到边缘控制节点以便去激活该边缘控制节点的cpu的可选操作4650b。
该方法可以包括用于确定在包括该边缘控制节点的工业控制系统中的多个边缘控制节点的计算要求的操作。在示例中，所述cpu基于编排服务器确定该cpu将被激活以满足针对工业控制系统的控制策略而被激活。在另一个示例中，编排服务器可以接收激活多个边缘控制节点中的该边缘控制节点的cpu的指示。
用于应用和客户端服务器框架的分布式动态架构
在经编排的系统中，在示例中，将应用定义为通过拓扑互连的一组模块。这些模块被部署在不同的逻辑节点上。每个逻辑节点可以对应于物理节点，但是，映射不必为1：1。只要满足资源要求，多个逻辑节点就可以映射到一个物理节点，或者可以在同一物理环境上部署多个模块。
随着不同模块的部署，可能会发生模块或节点的各种错误、崩溃或重启。为了提高所部署的应用的弹性，可以使用冗余来提高可用性。例如，模块可以被部署在两个节点上(例如，作为主节点和备份节点)。当主节点有错误或以其他方式发生故障时，编排器可以切换到备用节点以允许其接管。然而，关闭的模块的保存状态通常是非平凡的。在本文公开的系统和技术中，系统在应用拓扑中的相同级别上的节点之间包括对等关系，该对等关系可以充当自动备份节点或协调以生成备份。使用对等协调可以允许使用保存的状态，这可以包括在模块或节点发生故障或崩溃的情况下，监听通信信道并在不同的节点上重新部署模块。
当前的冗余解决方案是通过冗余方式手动定义或创建的。这使得可靠性很高，但是成本也相当可观，因为它需要资源的重复。手动冗余通常难以定义和维护。策略通常过于简单并且需要太多资源。此外，要求中央编排器标识冗余节点或替换故障节点既昂贵又缓慢。
在示例中，本文描述的技术可以创建模块的基于应用的通信模式的自动冗余节点。例如，当第一模块将数据发送到第二模块时，则主控第二模块的节点可以成为针对第一模块的自动冗余。由第一模块生成的数据被馈送到第二模块中，从而允许第一模块知道第二模块的输入是什么。当第一模块向多个模块而不是仅向第二模块发送数据时，则可能发生其他问题(或者当第二模块从除第一模块之外的模块接收输入时)。在这些场景下，可能难以在任何这些叶节点上创建冗余。相反，由同一层上的节点集合创建的对等网络可以协商冗余节点的状态。这些节点的网络可以在节点自身之间交换冗余集，而对应用的其余部分没有主要影响。
图47图示出示例应用连接图。在示例中，形成应用的不同模块可以以诸如图47所示的示例的布置来配置。连接示出了不同模块之间的数据流。这些模块使用可以在客户端/服务器或发布/订阅模式下运行的通信通道来发送数据。在该示例中，当编排器部署这些模块时，编排器可以选择将每个模块部署在单独的计算节点上，或者将多个模块部署在单个节点上。在该示例中，为简单起见，将单个模块部署在单个节点上。当多个模块在故障节点上时，或者当有模块有错误时(例如，当节点上的另一个模块没有错误时)，其他示例可以提供冗余选项。
在示例中，节点4720上的模块b正在向节点4740上的模块e和节点4730上的模块d两者发送数据。当模块b发生故障时，可以执行以下操作。该操作可以由诸如节点4710、节点4730和节点4740之类的对等节点执行。执行可以包括根据需要检测故障，在替换节点上重新部署模块b(例如，当节点4720发生故障时)，重新布线(例如，来自模块a的)输入或(例如，到模块e或模块d的)输出，以及恢复模块b的先前状态，该先前状态可以转移到替换节点。
在图47所示的示例中，模块b的邻居(例如，模块a、模块d和模块e)可以创建对等网络，目的是在模块b发生故障时(例如，当节点4720发生故障时)接管。在该示例中，相邻模块被定位以重新创建模块b的状态，因为模块a、模块d和模块e与模块b的输入和输出通道直接接触。这三个相邻模块可以经历领导者选举算法或用于选择替换节点的其他技术。
在示例中，用于模块b的可执行文件可以部署在三个节点(例如4710、4730或4740)中的一个或多个节点上，或者三个节点中的一个或多个节点可以管理冗余软件驻留在哪里。在示例中，在节点4720发生故障的情况下，这三个节点中的一个或多个节点可以管理路由输入或输出。在另一个示例中，即使未检测到故障，也可以路由数据(例如，出于冗余目的)。使用这些技术之一备份模块b允许在发生故障的情况下无缝切换到冗余节点，因为这些节点控制着数据流向何处。在示例中，一个或多个冗余节点可以在整个操作周期内利用软件运行影子节点作为冗余。
在图47所示的示例中，模块b具有模块a、模块d和模块e的邻居。这四个模块在b周围建立邻居(例如，对等网络)，并创建用于模块b发生故障时的应急计划。该计划可以包括使用领导者选举算法或其他技术来选择控制节点(例如，节点4710被选举为具有更多资源来运行针对模块b的冗余节点，诸如在节点4710的附加资源上)。控制节点或所选择的替换节点可以未直接连接到故障节点4720，可以存储模块b的冗余。当节点4720发生故障时，存在针对模块b的冗余，然后冗余节点可以无缝执行模块b。例如，模块a可以创建通道，以用于使模块b知道运行模块b的冗余版本的冗余节点。然后，模块b和冗余版本可以联系在一起，在模块b崩溃的情况下，模块b可以将状态详细信息发送到冗余模块，来使冗余模块知道上下文。
图48图示出具有冗余节点的应用的示例架构图。在图48中，主控模块a、模块d和模块e的3个节点(4810、4830和4840)形成对等网络。模块a是网络的领导者，并管理在冗余节点4825上主控模块b'。模块a还可以将其输出作为输入路由到节点4820和4825两者。在图48的示例中，即使模块b’没有连接任何模块，模块b’仍在不断地计算输出(例如，与模块b相同)。
通过该布置，应用独立于编排器4805(可用于设置应用或网络配置，然后可以断开连接)而拥有自己的弹性。应用的独立性可以允许与编排器4805完全断开，而不会牺牲可靠性。
在某些示例中，当主控模块的物理节点受到资源限制时，让模块b'运行所有计算可能不可行。然而，为了实现完全冗余，可以实现下文描述的选项之一。
一个选项包括在虚拟机中执行模块b。在该示例中，只要有可用资源允许，系统就可以制作虚拟机的副本，而不会损害应用的其余部分的操作(例如，通过等待停机或节点上的额外资源变得可用)。通过这样做，可以保留模块b的状态(例如，作为虚拟机的映像)。
在另一个选项中，模块b可以支持交换，这允许模块b具有用于提交其内部参数和状态信息到模块b'的接口。可以有规律地执行该冗余操作，以允许模块b保存其状态。更新的频率可以取决于模块b的大小以及是否可以在继续满足不同模块和整个应用的要求的同时进行更新。
在示例中，当模块d被选为领导者时，模块d可以侦听模块b'需要的所有通道以确保数据不丢失(例如，来自模块a的输出)。这使得可以在需要时将数据转发到模块b'。类似地，模块d可以将模块b设置为侦听通道(例如，来自模块a的输出)，而无需模块d直接侦听该通道。
在一些示例中，编排器或应用开发人员可以确定某个模块对于应用来说太重要或是单点故障。在该情况中，可以为该模块分派多于一个的冗余模块。例如，由三个节点形成的网络然后可以创建多个冗余模块(例如，模块b'和模块b”，未示出)。这些模块中的每个模块可以具有不同的同步策略以创建多样性或增加弹性。
通常，应用不存在于壁垒中，而是经常连接到其他应用。与上述技术和系统类似，用应用替换模块允许系统在微观或宏观水平上提供冗余。例如，应用i可以连接到应用ii，并成为创建冗余和冗余策略的领导者(例如，在应用发生故障的情况下)。
在级联故障或重大中断的情况下，创建这样的策略并允许应用拥有其自己的策略可以提供冗余而没有不必要的成本。完全分布式系统通常较难管理，但是由于缺乏可能变成单点故障的中央授权机构而具有较高程度的弹性。因此，在该情况下，每个应用可以具有其自己的可靠性策略(policy,strategies)。在示例中，应用可以互连并应用其自己的宏观可靠性策略。在示例中，当两个或多个模块、节点或应用发生故障时，剩余的模块、节点或应用可以充当用于该故障的冗余。例如，如果两个节点发生故障，则单个节点可以替换这两个故障节点，或者两个或更多个节点可以替换这两个故障节点。
当系统受到安全攻击时，具有宏观或微观可靠性策略的冗余应用或模块可以提供保护。可以在宏级别上检测到多个故障，并且相应地，策略可以改变。例如，当故障威胁可能会清除附近的应用时，部署的策略可以有目的地将远距离的邻居分派为社区的一部分，以从总故障中保存状态、模块或应用。当在图48的示例中考虑安全性时，模块f或模块c可以加入网络并被分派角色。该角色可以不是领导者而是社区的成员。换句话说，模块c可以不花费太多的资源来管理模块b'。取而代之，模块c可以制作模块b的冗余副本(例如，偶尔)，但不实例化它。这可能会牺牲一些无缝属性(例如，状态可能有点陈旧)，但会提供附加的保证和冗余层，而对整个系统的成本却最低。相同的概念可以应用于应用，使得如果本地数据中心的一部分变得不可用，则位于不同位置的另一个数据中心可以以稍微陈旧的状态和内部变量值来接管，从而允许操作继续进行。
图49a图示出根据示例的用于基于应用的通信模式在冗余节点上创建应用的自动冗余模块的方法的流程图。流程图4900a包括用于创建对等邻居网络的操作4910a。流程图4900a包括用于在冗余节点上呈现冗余模块的操作4920a，该冗余模块对应于节点上的应用的模块。流程图4900a包括用于检测该模块的节点的故障的操作4930a。流程图4900a包括用于通过将模块的输入和输出重新连接到冗余模块来激活冗余节点上的冗余模块的操作4940a。流程图4900a包括用于从模块中恢复先前的状态并将其传送到冗余模块的操作4950a。流程图4900a包括用于使用冗余模块继续执行模块的操作4960a。流程图4900a包括用于报告节点的故障的操作4970a。
图49b图示出根据示例的用于激活cpu的方法的流程图4900b。流程图4900b的操作可以由编排服务器执行。
流程图4900b包括用于配置包括一组分布式节点的应用以便在经编排的系统上运行的可选操作4910b。流程图4900b包括用于在第一节点上运行第一模块的操作4920b，该第一模块具有第一输出。流程图4900b包括用于在第二节点上运行第二模块的操作4930b，该第二模块使用第一输出作为输入。流程图4900b包括用于将来自第二模块的第二输出提供给在第三节点上运行的第三模块的操作4940b。
流程图4900b包括响应于检测到第二节点的故障而执行的、用于确定用于通过在第一节点和第三节点之间进行协调来重新部署第二模块的替换节点的操作4950b。在示例中，确定替换节点包括标识预配置为接收第一输出并操作第二模块的冗余节点。冗余节点可以与任何节点断开连接(例如，被阻止向任何节点提供输出)，直到冗余节点用作替换节点之后，例如接收输入并计算输出以保持第二模块的状态，但未连接到任何其他节点。在示例中，关于第二模块的参数和状态信息可以从第二节点、第一节点或第三节点被发送到冗余节点，诸如周期性地、每当产生输出时等等。在另一个示例中，响应于冗余节点发生故障，第二冗余节点可以被标识来成为替换节点(例如，用于关键模块)。
在示例中，确定冗余节点包括确定连接到第二节点的一组节点。一组节点可以包括一个或多个输入节点或一个或多个输出节点，诸如具有方向指示。例如，替换节点可以连接到第一节点以接收来自第一模块的输出，并且连接到第三节点以将来自第二模块的输出提供给第三模块。
进一步的操作可以包括当生成第一输出时，诸如在第一节点处保存第二模块的冗余状态。在示例中，编排服务器可以最初在节点上生成模块的配置(例如，第一节点上的第一模块等)。在该示例中，例如，在诸如第二节点故障之类的任何故障之前，编排服务器可以被断开连接。在没有编排服务器帮助的情况下，第一节点和第三节点可以协调以确定替换节点。在示例中，第二节点可以被植入到虚拟机上。然后，可以基于第二节点在虚拟机上的映像在替换节点中实例化第二模块。
iot设备和网络
可以结合各种设备部署来实现上述技术，包括在任何数量的iot网络和拓扑的设备部署中。因此，将理解的是，本技术的各种实施例可以涉及异构网络和同构网络之间的边缘设备、雾设备和中间设备以及云实体的协调。在以下段落中提供了这种网络的一些示例拓扑和布置。
图50图示用于通过链路而耦合到相应的网关的各个物联网(iot)网络的示例域拓扑。物联网(iot)是这样的概念，其中，大量计算设备互连至彼此并互连至因特网，以便在非常低的级别上提供功能和数据采集。因此，如本文中所使用，iot设备可包括执行功能(诸如感测或控制，等等)、与其他iot设备和范围更广的网络(诸如因特网)进行通信的半自主设备。
iot设备是可以在网络上通信的物理对象，并且可以包括传感器、致动器、和其他输入/输出组件，诸如以从现实世界环境中收集数据或执行动作。例如，iot设备可包括嵌入或附接到日常物品(诸如，建筑物、车辆、包裹等)的低功率设备，以提供对这些物品的附加水平的人工感官知觉。最近，iot设备已变得越来越流行，因此使用这些设备的应用已经激增。
iot设备常在存储器、尺寸或功能方面受限，从而允许部署较大数量的设备，以实现与较少数量的较大设备类似的成本。然而，iot设备可以是智能电话、膝上型设备、平板设备、或pc、或其他较大的设备。而且，iot设备可以是虚拟设备，诸如智能电话或其他计算设备上的应用。iot设备可包括iot网关，这些iot网关用于将iot设备耦合至其他iot设备并耦合至云应用，以进行数据存储、过程控制，等等。
iot设备的网络可包括商用和家用自动化设备，诸如，给水系统、配电系统、管道控制系统、工厂控制系统、灯开关、恒温器、锁、相机、警报、运动传感器，等等。iot设备可以是通过远程计算机、服务器和其他系统可访问的，从而例如控制系统或访问数据。
因特网和类似网络的未来增长可涉及非常大量的iot设备。相应地，在本文中讨论的技术的情境中，用于此类未来联网的大量创新将解决所有这些层无障碍地增长、发现并制造能访问的经连接资源以及支持隐藏并分隔经连接资源的能力的需求。可使用任何数量的网络协议和通信标准，其中，每种协议和标准被设计成解决特定的目标。此外，协议是支持无论地点、时间或空间而进行操作的人类能访问服务的结构的部分。创新包括：服务交付和相关联的基础结构，诸如，硬件和软件；安全增强；以及基于在服务水平和服务交付协议中指定的服务质量(qos)条款的服务供应。如将理解的那样，使用诸如在上文讨论的系统示例中介绍的那样的iot设备和网络的iot设备和网络在包括有线和无线技术的组合的异构连接性网络中呈现出大量新挑战。
图50具体提供可用于大量物联网(iot)网络的域拓扑的简化图，大量iot网络包括iot设备5004，其中iot网络5056、5058、5060、5062通过主干链路5002耦合至相应的网关5054。例如，大量iot设备5004可与网关5054通信，并且可通过网关5054彼此通信。为了简化该图，不是每个iot设备5004或通信链路(例如，链路5016、5022、5028或5032)都被标记。主干链路5002可包括任何数量的有线或无线技术(包括光学网络)，并且可以是局域网(lan)、广域网(wan)或因特网的部分。另外，此类通信链路促进iot设备5004与网关5054两者之间的光学信号路径，包括使用促进各种设备的互连的复用/解复用组件。
网络拓扑可包括任何多种类型的iot网络，诸如，利用网络5056使用蓝牙低能量(ble)链路5022而提供的网格网络。可能存在的其他类型的iot网络包括：用于通过ieee802.11
这些iot网络中的每一个iot网络可为新技术特征(诸如，如本文中所描述的那些技术特征)提供机会。改进的技术和网络可实现设备和网络的指数式增长，包括将iot网络用作雾设备或雾系统。随着此类改进技术的使用增长，可在无需直接的人类干预的情况下开发iot网络以实现自管理、功能进化和协同。改进的技术甚至可使iot网络能够在没有集中式受控的系统的情况下运作。相应地，本文中描述的改进的技术可用于远超当前实现方式地使网络管理和操作功能自动化并增强网络管理和操作功能。
在示例中，iot设备5004之间的(诸如，主干链路5002上的)通信可受分散化系统保护以进行认证、授权和记账(aaa)。在分散化aaa系统中，可跨互连的异构网络基础结构实现分布式支付、信贷、审计、授权和认证系统。这允许系统和网络迈向自主操作。在这些类型的自主操作中，机器甚至可订立人力资源合约，并且与其他机器网络商议伙伴关系。这可允许针对概括的计划服务水平协议实现共同目标和均衡的服务交付，并且实现提供计量、测量、可追溯性和可跟踪性的解决方案。新供应链结构和方法的产生可在没有任何人类参与的情况下使大量服务能够被产生、被挖掘价值以及坍塌。
此类iot网络可通过将感测技术(诸如，声、光、电子通信量、面部和模式识别、嗅觉、振动)集成到iot设备之间的自主组织中而进一步被增强。对传感系统的集成可允许对于针对合同服务目标、基于编排和服务质量(qos)的分群以及资源融合的服务交付的系统性和自主的通信和协调。基于网络的资源处理的单独的示例中的一些包括以下示例。
网格网络5056例如可由执行内联式数据-信息变换的系统来增强。例如，包括多链路网络的处理资源的自形成的链能以高效的方式分布原始数据向信息的变换、以及在资产和资源之间进行区分的能力以及对每一者的相关联的管理。此外，可插入基于基础结构和资源的恰当组件的信任和服务索引以改善数据完整性、质量、保证，并递送数据置信度的度量。
wlan网络5058例如可使用执行标准转换的系统以提供多标准连接性，从而实现使用不同协议进行通信的iot设备5004。进一步的系统可提供跨多标准基础结构的无缝的互连接性，该多标准基础结构包括可见的因特网资源和隐藏的因特网资源。
蜂窝网络5060中的通信例如可由卸载数据的系统、将通信延伸至更远程的设备的系统或卸载数据的系统和将通信延伸至更远程的设备的系统两者来增强。lpwa网络5062可包括执行非网际协议(ip)至ip互连、寻址和路由的系统。进一步地，iot设备5004中的每一个可包括用于与那个设备进行广域通信的适当的收发机。进一步地，每个iot设备5004可包括用于使用附加的协议和频率进行通信的其他收发机。关于图52和图53中所描绘的iot处理设备的通信环境和硬件进一步讨论了这一点。
最终，可装备iot设备的集群以与其他iot设备以及与云网络通信。这可允许iot设备在多个设备之间形成自组织(ad-hoc)网络，从而允许它们充当单个设备，该单个设备可被称为雾设备。下面进一步参考图51来讨论该配置。
图51示出了云计算网络，该云计算网络与在该云计算网络的边缘处作为雾设备操作的iot设备(设备5102)的网格网络通信。iot设备的网格网络可被称为在云5100的边缘处操作的雾5120。为了简化该图，没有对每个iot设备5102进行标记。
可以将雾5120认为是大规模地互连的网络，其中数个iot设备5102例如通过无线电链路5122与彼此进行通信。作为示例，该经互连的网络可使用由开放连接性基金会tm(ocf)发布的互连规范来促进。该标准允许设备发现彼此并建立通信以用于互连。也可使用其他互连协议，包括例如，最优链路状态路由(olsr)协议、至移动自组织联网的更好方式(b.a.t.m.a.n)路由协议、或oma轻量型m2m(lwm2m)协议，等等。
尽管在本示例中展示三种类型的iot设备5102：网关5104、数据聚合器5126、以及传感器5128，但可以使用iot设备5102和功能的任何组合。网关5104可以是提供云5100与雾5120之间的通信的边缘设备，并且还可为从传感器5128获得的数据(诸如，运动数据、流数据、温度数据等)提供后端处理功能。数据聚合器5126可从任何数量的传感器5128收集数据，并执行处理功能以用于分析。结果、原始数据或这两者可通过网关5104传递至云5100。传感器5128可以是例如能够既收集数据又处理数据的完整的iot设备5102。在一些情况下，传感器5128在功能上可能更受限制，该功能例如，收集数据并允许数据聚合器5126或网关5104处理该数据。
来自任何iot设备5102的通信可以沿着iot设备5102中的任何设备之间的方便路径(例如，最方便的路径)传递以到达网关5104。在这些网络中，互连的数目提供了大量冗余，这允许即使在损失数个iot设备5102的情况下也维持通信。此外，网格网络的使用可允许使用功率非常低或位于距基础结构一定距离的iot设备5102，因为连接到另一个iot设备5102的范围可能比连接到网关5104的范围小得多。
从这些iot设备5102提供的雾5120可以被呈现给云5100中的设备(诸如，服务器5106)作为位于云5100的边缘处的单个设备，例如，雾设备。在该示例中，来自雾设备的警报可以被发送而不被识别为来自雾5120内的特定iot设备5102。按此方式，雾5120可被视为分布式平台，该分布式平台提供计算和存储资源以执行处理或数据密集型任务(诸如，数据分析法、数据聚合和机器学习，等等)。
在一些示例中，可以使用命令性编程风格来配置iot设备5102，例如，每个iot设备5102具有特定功能和通信伙伴。然而，形成雾设备的iot设备5102能以声明性编程风格配置，从而允许iot设备5102重新配置它们的操作和通信，诸如，响应于条件、查询和设备故障来确定所需的资源。作为示例，来自位于服务器5106处的用户关于由iot设备5102监测的装备子集的操作的查询可以导致雾5120设备选择回答该查询所需的iot设备5102，诸如，特定的传感器5128。然后，在由雾5120设备发送到服务器5106以回答该查询之前，可由传感器5128、数据聚合器5126或网关5104的任何组合来聚合并分析来自这些传感器5128的数据。在该示例中，雾5120中的iot设备5102可以基于查询选择使用的传感器5128，诸如添加来自流量传感器或温度传感器的数据。此外，如果iot设备5102中的一些不可操作，则雾5120设备中的其他iot设备5102可以提供类似的数据(如果可得的话)。
在示例中，工作负荷编排和操作的各个方面可以适合于图51所描绘的各种网络拓扑和方式。例如，系统可以与iot设备5102协同建立在云5100中执行的各种工作负荷。可以从边缘(例如，从iot设备5102)在云5100或雾5120中编排这些工作负荷，或者可以通过云5100或雾5120在边缘上编排这些工作负荷。这样的概念也可以应用于网关5104和数据聚合器5126以及网络拓扑内的其他设备和节点。
在其他示例中，上文参考以上描述的系统而描述的操作和功能可由电子处理系统的示例形式的iot设备机器来具体化，在该电子处理系统内，可执行指令的集合或序列以使该电子处理系统执行根据示例的本文中讨论的方法中的任一方法。该机器可以是iot设备或iot网关，包括由以下各项的多个方面具体化的机器：个人计算机(pc)、平板pc、个人数字助理(pda)、移动电话或智能电话、或能够执行指定要由该机器采取的动作的指令(顺序地或以其他方式)的任何机器。此外，尽管在上述示例中可能仅描绘并引用了单个机器，但是也应当认为此类机器包括单独地或联合地执行一组(或多组)指令以执行本文中所讨论的方法中的任何一种或多种方法的机器的任何集合。此外，对于基于处理器的系统的这些示例和类似示例应当被认为包括由处理器(例如，计算机)控制或操作以单独地或联合地执行指令来执行本文中所讨论的方法中的任何一种或多种方法的一个或多个机器的任何集合。
图52图示与数个物联网(iot)设备通信的云计算网络或云5200的图。云5200可表示因特网，或者可以是局域网(lan)、或广域网(wan)，诸如，用于公司的专属网络。iot设备可包括按各种组合分组的任何数量的不同类型的设备。例如，交通控制组5206可包括沿城市中的街道的iot设备。这些iot设备可包括停车灯、交通流监视器、相机、天气传感器，等等。交通控制组5206或其他子组可通过有线或无线链路5208(诸如lpwa链路、光学链路，等等)与云5200通信。进一步地，有线或无线子网5212可允许iot设备诸如通过局域网、无线局域网等等来彼此通信。iot设备可使用另一设备(诸如网关5210或5228)来与远程位置(诸如云5200)通信；iot设备也可使用一个或多个服务器5230来促进与云5200或与网关5210的通信。例如，一个或多个服务器5230可充当中间网络节点以支持在局域网之间的局部边缘云或雾实现。而且，所描绘的网关5228可在诸如具有各种iot设备5214、5220、5224的云-网关-许多边缘设备配置中操作，各种iot设备5214、5220、5224约束于云5200中的资源的分派和使用，或对于云5200中的资源的分派和使用是动态的。
iot设备的其他示例组可包括远程气象站5214、本地信息终端5216、警报系统5218、自动化柜员机5220、警报面板5222或移动车辆(诸如，应急车辆5224或其他车辆5226)，等等。这些iot设备中的每一个可与其他iot设备、与服务器5204、与另一iot雾设备或系统(未示出但在图51中描绘)、或与其中的组合通信。这些iot设备的组可部署在各种住宅、商业和工业设定(包括私有环境或公共环境两者)中。
如从图52可见，大量iot设备可通过云5200进行通信。这可允许不同的iot设备自主地请求信息或将信息提供给其他设备。例如，iot设备的组(例如，交通控制组5206)可从可在没有人类干预的情况下提供预报的远程气象站的组5214请求当前的天气预报。此外，可由自动化柜员机5220向应急车辆5224警告盗窃在进行中。当应急车辆5224朝自动化柜员机5220行进时，它可访问交通控制组5206以请求清空该位置，例如，通过在足够的时间内亮起红灯以阻止交叉路口处的交叉交通流，以使应急车辆5224能够畅通无阻地进入该交叉路口。
可装备iot设备的集群(诸如，远程气象站5214或交通控制组5206)以与其他iot设备以及与云5200进行通信。这可允许iot设备在多个设备之间形成自组织网络，从而允许它们充当单个设备，该单个设备可被称为雾设备或系统(例如，如上文中参照图51所描述)。
图53是可存在于iot设备5350中用于实现本文中描述的技术的组件的示例的框图。iot设备5350可包括在示例中示出或在上文公开内容中引用的组件的任何组合。这些组件可被实现为ic、ic的部分、分立电子器件，或其他模块、逻辑、硬件、软件、固件或其适用于iot设备5350中的组合，或作为以其他方式被并入在更大的系统的机架内的组件。此外，图53的框图旨在描绘iot设备5350的组件的高级视图。然而，可省略所示出的组件中的一些组件，可存在附加的组件，并且所示出的组件的不同布置可在其他实现方式中发生。
iot设备5350可包括处理器5352，该处理器5352可以是微处理器、多核处理器、多线程处理器、超低电压处理器、嵌入式处理器，或其他已知的处理元件。处理器5352可以是芯片上系统(soc)的部分，在该soc中，处理器5352和其他组件被形成到单个集成电路或单个封装中，诸如，来自英特尔的爱迪生tm(edisontm)或伽利略tm(galileotm)soc板。作为示例，处理器5352可包括基于英特尔
处理器5352可通过互连5356(例如，总线)来与系统存储器5354通信。任何数量的存储器设备可被用来提供给定量的系统存储器。作为示例，存储器可以是根据联合电子器件工程委员会(jedec)设计的随机存取存储器(ram)，诸如，ddr或移动ddr标准(例如，lpddr、lpddr2、lpddr3或lpddr4)。在各种实现方式中，单独的存储器设备可以是任何数量的不同封装类型，诸如单管芯封装(sdp)、双管芯封装(ddp)或四管芯封装(q17p)。在一些示例中，这些设备可以直接焊接到主板上，以提供较简单的解决方案，而在其他示例中，设备被配置为一个或多个存储器模块，这些存储器模块进而通过给定的连接器耦合到主板。可使用任何数量的其他存储器实现方式，诸如，其他类型的存储器模块，例如，不同种类的双列直插存储器模块(dimm)，包括但不限于microdimm(微dimm)或minidimm(迷你dimm)。
为了提供对信息(诸如，数据、应用、操作系统等)的持久性存储，存储5358也可经由互连5356而耦合至处理器5352。在示例中，存储5358可经由固态盘驱动器(ssdd)来实现。可用于存储5358的其他设备包括闪存卡(诸如，sd卡、microsd卡、xd图片卡，等等)和usb闪存驱动器。在低功率实现中，存储5358可以是与处理器5352相关联的管芯上存储器或寄存器。然而，在一些示例中，存储5358可使用微硬盘驱动器(hdd)来实现。此外，附加于或替代所描述的技术，可将任何数量的新技术用于存储5358，诸如，阻变存储器、相变存储器、全息存储器或化学存储器，等等。
组件可通过互连5356进行通信。互连5356可包括任何数量的技术，包括工业标准架构(isa)、扩展isa(eisa)、外围组件互联(pci)、外围组件互联扩展(pcix)、pci快速(pcie)或任何数量的其他技术。互连5356可以是例如在基于soc的系统中使用的专属总线。其他总线系统可被包括，诸如i2c接口、spi接口、点对点接口、功率总线，等等。
互连5356可将处理器5352耦合至网格收发机5362，以便例如与其他网格设备5364通信。网格收发机5362可使用任何数量的频率和协议，诸如，ieee802.15.4标准下的2.4千兆赫兹(ghz)传输，使用如由蓝牙
网格收发机5362可使用用于不同范围的通信的多种标准或无线电来进行通信。例如，iot设备5350可使用基于ble的或另一低功率无线电的本地收发机与接近的(例如，在约10米内的)设备通信以节省功率。更远的(例如，在约50米内的)网格设备5364可通过zigbee或其他中间功率的无线电而被联络到。这两种通信技术能以不同的功率水平通过单个无线电发生，或者可通过分开的收发机而发生，分开的收发机例如使用ble的本地收发机以及使用zigbee的分开的网格收发机。
无线网络收发机5366可被包括，以经由局域网协议或广域网协议来与云5300中的设备或服务通信。无线网络收发机5366可以是遵循ieee802.15.4或ieee802.15.4g标准等的lpwa收发机。iot设备5350可使用由semtech和lora联盟开发的lorawantm(长距离广域网)在广域上通信。本文中所描述的技术不限于这些技术，而使可与实现长距离、低带宽通信(诸如，sigfox和其他技术)的任何数量的其他云收发机一起使用。此外，可使用其他通信技术，诸如，在ieee802.15.4e规范中描述的时分信道跳跃。
除了针对如本文中所述的网格收发机5362和无线网络收发机5366而提及的系统之外，还可使用任何数量的其他无线电通信和协议。例如，无线电收发机5362和5366可包括使用扩展频谱(spa/sas)通信以实现高速通信的lte或其他蜂窝收发机。此外，可使用任何数量的其他协议，诸如，用于中速通信和供应网络通信的
无线电收发机5362和5366可包括与任何数量的3gpp(第三代合作伙伴计划)规范(尤其是长期演进(lte)、长期演进-高级(lte-a)和长期演进-高级加强版(lte-apro))兼容的无线电。可以注意到，可选择与任何数量的其他固定的、移动的或卫星通信技术和标准兼容的无线电。这些可包括例如任何蜂窝广域无线电通信技术，其可包括例如第5代(5g)通信系统、全球移动通信(gsm)无线电通信系统、通用分组无线电服务(gprs)无线电通信技术、或gsm演进(edge)增强数据速率无线电通信技术、umts(通用移动电信系统)通信技术，除了上面列出的标准外，任何数量的卫星上行链路技术都可以用于无线网络收发器5366，包括例如符合由itu(国际电信联盟)或etsi(欧洲电信标准协会)发布标准的无线电等。本文中所提供的示例因此可被理解为适用于现有的和尚未制定的各种其他通信技术。
网络接口控制器(nic)5368可被包括以提供到云5300或到其他设备(诸如网格设备5364)的有线通信。有线通信可提供以太网连接，或可基于其他类型的网络，诸如控制器区域网(can)、本地互连网(lin)、设备网络(devicenet)、控制网络(controlnet)、数据高速路+、现场总线(profibus)或工业以太网(profinet)，等等。附加的nic5368可被包括以允许到第二网络的连接，例如，nic5368通过以太网提供到云的通信，并且第二nic5368通过另一类型的网络提供到其他设备的通信。
互连5356可将处理器5352耦合至外部接口5370，该外部接口5370用于连接外部设备或子系统。外部设备可包括传感器5372，诸如加速度计、水平传感器、流量传感器、光学光传感器、相机传感器、温度传感器、全球定位系统(gps)传感器、压力传感器、气压传感器，等等。外部接口5370可进一步用于将iot设备5350连接至致动器5374(诸如，电源开关、阀致动器、可听见声音发生器、视觉警告设备等)。
在一些任选的示例中，各种输入/输出(i/o)设备可存在于iot设备5350内，或可连接至iot设备5350。例如，显示器或其他输出设备5384可被包括以显示信息，诸如传感器读数或致动器位置。输入设备5386(诸如，触摸屏或按键)可被包括以接受输入。输出设备5384可包括任何数量的音频或视觉显示形式，包括：简单视觉输出，诸如二进制状态指示器(例如，led)；多字符视觉输出；或更复杂的输出，诸如显示屏(例如，lcd屏)，其具有从iot设备5350的操作生成或产生的字符、图形、多媒体对象等的输出。
电池5376可为iot设备5350供电，但是在其中iot设备5350被安装在固定位置的示例中，该iot设备5350可具有耦合至电网的电源。电池5376可以是锂离子电池、金属-空气电池(诸如锌-空气电池、铝-空气电池、锂-空气电池)，等等。
电池监视器/充电器5378可被包括在iot设备5350中以跟踪电池5376的充电状态(soch)。电池监视器/充电器5378可用于监视电池5376的其他参数以提供失效预测，诸如电池5376的健康状态(soh)和功能状态(sof)。电池监视器/充电器5378可包括电池监视集成电路，诸如来自线性技术公司(lineartechnologies)的ltc4020或ltc2990、来自亚利桑那州的凤凰城的安森美半导体公司(onsemiconductor)的adt7488a、或来自德克萨斯州达拉斯的德州仪器公司的ucd90xxx族的ic。电池监视器/充电器5378可通过互连5356将电池5376上的信息传递至处理器5352。电池监视器/充电器5378也可包括允许处理器5352直接监视电池5376的电压或来自电池5376的电流的模数(adc)转换器。电池参数可被用于确定iot设备5350可执行的动作，诸如传输频率、网格网络操作、感测频率，等等。
功率块5380或耦合至电网的其他电源可与电池监视器/充电器5378耦合以对电池5376充电。在一些示例中，功率块5380可用无线功率接收机代替，以便例如通过iot设备5350中的环形天线来无线地获得功率。无线电池充电电路(诸如来自加利福尼亚州的苗比达市的线性技术公司的ltc4020芯片，等等)可被包括在电池监视器/充电器5378中。所选择的特定的充电电路取决于电池5376的尺寸，并因此取决于所需的电流。可使用由无线充电联盟(airfuelalliance)颁布的airfuel标准、由无线电力协会(wirelesspowerconsortium)颁布的qi无线充电标准、或由无线电力联盟(allianceforwirelesspower)颁布的rezence充电标准等等执行充电。
存储5358可包括用于实现本文中描述的技术的软件、固件或硬件命令形式的指令5382。虽然此类指令5382被示出为被包括在存储器5354和存储5358中的代码块，但是可以理解，可用例如被建立到专用集成电路(asic)中的硬连线电路替换代码块中的任一个。
在示例中，经由存储器5354、存储5358或处理器5352提供的指令5382可具体化为非瞬态机器可读介质5360，该非瞬态机器可读介质5360包括用于指示处理器5352执行iot设备5350中的电子操作的代码。处理器5352可通过互连5356访问非瞬态机器可读介质5360。例如，非瞬态机器可读介质5360可由针对图53的存储5358所描述的设备来具体化，或者可包括特定的存储单元，诸如光盘、闪存驱动器或任何数量的其他硬件设备。非瞬态机器可读介质5360可包括用于指示处理器5352执行例如像参照上文中描绘的操作和功能的(多个)流程图和(多个)框图而描述的特定的动作序列或动作流的指令。
在进一步的示例中，机器可读介质也包括任何有形介质，该有形介质能够存储、编码或携带供由机器执行并且使机器执行本公开方法中的任何一种或多种方法的指令，或者该有形介质能够储存、编码或携带由此类指令利用或与此类指令相关联的数据结构。“机器可读介质”因此可包括但不限于固态存储器、光学介质和磁介质。机器可读介质的特定示例包括非易失性存储器，作为示例，包括但不限于：半导体存储器设备(例如，电可编程只读存储器(eprom)、电可擦除可编程只读存储器(eeprom)和闪存设备；诸如内部硬盘及可移除盘之类的磁盘；磁光盘；以及cd-rom和dvd-rom盘。可使用传输介质，经由网络接口设备，利用数个传输协议中的任何一种协议(例如，http)，进一步通过通信网络来传输或接收由机器可读介质具体化的指令。
应当理解，在本说明书中所描述的功能单元或能力可被称为或标记为组件或模块，从而特别强调其实现的独立性。此类组件可由任何数量的软件或硬件形式具体化。例如，组件或模块可被实现为硬件电路，该硬件电路包括：定制的超大规模集成(vlsi)电路或门阵列，诸如逻辑芯片、晶体管之类的现成的半导体，或其他分立组件。组件或模块也可被实现在可编程硬件器件(诸如现场可编程门阵列、可编程阵列逻辑、可编程逻辑器件等等)中。组件或模块也能以软件来实现，以供由各种类型的处理器执行。可执行代码的所标识的组件或模块可以例如包括计算机指令的一个或多个物理或逻辑块，其例如可被组织成例如对象、过程、或函数。然而，所标识的组件或模块的可执行文件不必在物理上在一起，而是可包括存储在不同位置中的不同指令，当这些指令在逻辑上结合在一起时，包括组件或模块，并且针对该组件或模块实现所声称的目的。
实际上，可执行代码的组件或模块可以是单条指令或许多条指令，并且甚至可以分布在若干不同的代码段上，分布在不同的程序之间，以及跨若干存储器设备或处理系统而分布。具体而言，所描述的过程的一些方面(诸如代码重写和代码分析)可发生在与代码部署在其中的处理系统(例如，在嵌入在传感器或机器人中的计算机中)不同的处理系统(例如，在数据中心中的计算机中)上。类似地，操作数据在此可被标识并图示在组件或模块内，并且能以任何合适的形式被具体化并被组织在任何合适类型的数据结构内。操作数据可以被收集为单个数据集，或者可分布在不同位置上(包括分布在不同的存储设备上)，并且可以至少部分地仅作为电子信号而存在于系统或网络上。组件或模块可以是无源或有源的，包括用于执行所需功能的代理。
示例
当前所描述的方法、系统和设备实施例的附加示例包括下列非限制性的配置。下列非限制性示例中的每一个示例可以独立存在，或可以与以下所提供的或遍及本公开的其他示例中的一个或更多示例按照任何排列或组合进行结合。
示例1中一种用于软件定义的工业系统的操作的方法，包括：建立软件定义的工业系统的相应功能定义，所述软件定义的工业系统用于与多个设备对接，其中所述多个设备包括相应的传感器和相应的执行器；以及使用所述相应的功能定义来运行所述软件定义的工业系统。
在示例2中，示例1的主题包括：建立动态数据模型以定义所述软件定义的工业系统的多个组件的属性；以及基于与所述多个组件相关联的操作元数据来更新所述动态数据模型。
在示例3中，示例2的主题包括：其中，所述多个组件包括相应的应用、设备、传感器或架构定义。
在示例4中，示例2-3的主题包括：其中，多个组件包括设备，其中，所述设备代表传感器全体。
在示例5中，示例2-4的主题包括：其中，所述动态数据模型被更新以指示对所述多个组件中的组件的子集中的所述动态数据模型的更改，并且其中所述动态数据模型将基于资源可用性更改或所述组件的子集发生的错误情况进行更新。
在示例6中，示例2-5的主题包括：其中，建立所述动态数据模型包括定义强制字段和对所述动态数据模型的更改的限制。
在示例7中，示例2-6的主题包括：其中，所述操作元数据表示与所述多个组件中的组件相关联的值的概率估计。
在示例8中，示例2-7的主题包括：向所述多个组件中的组件查询元数据扩展规则；从所述组件接收响应于所述查询的响应；其中，所述动态数据模型的更新还基于所述元数据扩展规则以及与更新响应数据字段相关联的置信度或相关性得分。
在示例9中，示例2-8的主题包括：监视来自所述多个组件的所述数据流，以便标识所述操作元数据；从所述多个组件中检测一个或多个模式；基于检测到的一个或多个模式，标识所述动态数据模型的变更；其中，所述动态数据模型的更新包括并入所标识的变更。
在示例10中，示例2-9的主题包括：基于更新的动态数据模型，在边缘、雾或云网络中执行系统操作。
在示例11中，示例1-10的主题包括：在所述软件定义的工业系统中定义至少一个条件以进行数据模型评价；从所述软件定义的工业系统中的多个传感器获取数据；标识至少一个模式、规则或阈值，以进行数据模型修改；使用至少一个标识出的模式、规则或标识出的阈值评价来自所述多个传感器的数据；基于所述至少一个标识出的模式、规则或标识出的阈值，定义对所述数据模型的修改；以及并入对用于所述多个传感器的所述数据模型的修改以及与所述多个传感器相关联的数据流。
在示例12中，示例11的主题包括：向数据模型管理员请求批准所述数据模型修改；以及从所述数据模型管理员获得对所述数据模型修改的批准；其中，响应于接收到对所述数据模型修改的批准，将所述修改并入所述数据模型。
在示例13中，示例11-12的主题包括：基于所述数据模型修改，在所述软件定义的工业系统中实现对数据处理操作的更改。
在示例14中，示例1-13的主题包括：为跨所述软件定义的工业系统中的分布式资源池执行的功能块建立扩展的编排器逻辑规则集。
在示例15中，示例14的主题包括针对所述分布式资源池执行网络带宽、资源容量、当前状态和控制应用约束的动态发现。
在示例16中，示例14-15的主题包括：通过与相应传统应用对接的垫层来与相应传统设备建立编排。
在示例17中，示例14-16的主题包括：其中扩展的编排器规则集包括以下中的一个或多个：应用周期时间、应用运行时、应用输入/输出信号依赖性或应用进程顺序。
在示例18中，示例14-17的主题包括：基于应用周期、应用部署的运行时依赖性以及所述应用部署的当前状态，评价所述应用部署的功能块应用时序依赖性；以及基于所评价的功能块应用时序依赖性，在所述软件定义的工业系统的节点之间分配所述应用部署的相应应用。
在示例19中，示例14-18的主题包括：监视应用部署的各个功能块；基于当前和历史数据更新优化和预测预报；响应于从所述各个功能块中的一个或多个功能块中检测到系统异常，根据控制策略来编排分布式资源池中的所述各个功能块中的一个或多个功能块的执行。
在示例20中，示例19的主题包括：确定所述控制策略是否可行，其中，响应于确定所述控制策略可行，执行所述各个功能块中的一个或多个功能块的编排执行。
在示例21中，示例20的主题包括：响应于确定所述控制策略不可行，对所述各个功能块中的所述一个或多个功能块的至少一部分实施降级或断线控制策略。
在示例22中，示例14-21的主题包括：其中所述分布式资源池包含跨以下中的一个或多个的应用：在单个本机设备上运行的单个应用，其中第二冗余应用可用在附近本机设备上；在多个本机设备中运行的多个经协调应用；在单个虚拟机上运行的多个经协调应用，其中虚拟机在单个嵌入式设备或服务器上运行；跨多个虚拟机运行的多个经协调应用，其中每个虚拟机都在专用嵌入式设备或服务器中运行；跨越一个虚拟机中包含的多个容器的多个经协调应用，其中该虚拟机在专用嵌入式设备或服务器中运行；或者跨越多个容器的多个经协调应用，其中这些容器在多个嵌入式设备或服务器上运行。
在示例23中，示例14-22的主题包括：其中，为跨分布式资源池执行的功能块建立扩展的编排器逻辑规则集包括：标识应用特定的依赖性；基于所标识的依赖性动态创建分布式和从属应用的编排组；预测编排事件；检测所预测的编排事件；以及响应于检测到所预测的编排事件而优化资源放置。
在示例24中，示例23的主题包括：其中，预测编排事件包括在示例场景中动态分析和模拟网络带宽以及在所述示例场景中分析所述编排事件的发生。
在示例25中，示例1-24的主题包括：与传统组件建立通信，其中，所述传统组件是传统软件模块或传统硬件设备；以及建立与可编排组件的通信，其中所述可编排组件是可编排软件模块或可编排硬件设备；以及建立经组织的编排，以便控制和分配所述可编排组件和所述传统组件之间的工作负荷。
在示例26中，示例25的主题包括：建立编排垫层以便配置传统软件模块，并且其中，所述编排垫层适于向所述传统软件模块提供自定义配置；以及基于所述自定义配置直接与所述传统软件模块进行通信，以用于所述工作负荷的所述控制和分配。
在示例27中，示例26的主题包括：通过编排垫层的应用编程接口(api)将自定义配置传送给所述传统软件模块；以及通过所述编排垫层的所述api从所述传统软件模块传送传统模块通信信息，其中，与所述传统软件模块的通信进一步使用所述传统模块通信信息来执行。
在示例28中，示例26-27的主题包括：经由所述编排软件模块的应用编程接口(api)将第二配置传送到可编排软件模块；以及基于所述第二配置与所述可编排软件模块直接通信，以用于所述工作负荷的所述控制和分配。
在示例29中，示例25-28的主题包括：基于从可编排硬件设备的代理收集的遥测，通过所述可编排硬件设备与所述传统硬件设备建立经组织的编排，该遥测指示所述传统硬件设备的可用资源；以及通过所述可编排硬件设备的所述代理将基于所述经组织的编排的工作负荷部署到所述传统硬件设备。
在示例30中，示例25-29的主题包括：基于从可编排硬件设备的代理收集的遥测来建立与所述可编排硬件设备的经组织的编排，该遥测指示所述可编排硬件设备的可用资源；以及通过所述可编排硬件设备的所述代理将基于所述经组织的编排的工作负荷部署到所述可编排硬件设备。
在示例31中，示例25-30的主题包括：在编排器的编排引擎处接收来自各个可编排设备的可用资源的描述，其中所述可用资源的描述是基于从所述各个可编排设备接收到的遥测；基于对可用资源的所述描述，组织从所述编排器到所述各个可编配设备定义的编排的分层结构；以及基于所述编排的分层结构将工作负荷从所述编排引擎分配到所述各个可编排设备。
在示例32中，示例31的主题包括：其中，所述分层结构是编排的功能分层结构，其中，所述分层结构通过使用子编排软件模块来定义应用编排，并且其中，所述子编排软件模块包括用于网络编排、虚拟机编排、任务编排和存储编排的相应软件模块。
在示例33中，示例31-32的主题包括：其中，所述编排的分层结构是单级分层结构，并且其中，所述编排引擎将所述各个可编排设备的子集分派为运行相应工作负荷的一部分。
在示例34中，示例31-33的主题包括：其中，所述编排的分层结构是多级分层结构，所述多级分层结构包括在所述多级分层结构的中间层上具有相应的协调编排引擎的子编排，其中所述编排引擎和编排器在所述多级分层结构的顶层运行，并且其中所述相应的协调编排引擎操作用于协调所述遥测的收集和所述工作负荷在所述多级分层结构的底层上的各个可编排设备之间的分配。
在示例35中，示例34的主题包括：其中，各个可编排设备的组被组织为各个集群，并且其中各个子编排器协调所述遥测的收集和所述工作负荷在所述各个集群中的分配。
在示例36中，示例31-35的主题包括：其中，所述编排的分层结构是多级分层结构，所述多级分层结构包括在所述多级分层结构的中间层上的主可编排设备，以及在所述多级分层结构的底层上的从节点，其中所述编排引擎和编排器在所述多级分层结构的顶层上运行，并且其中所述主可编排设备包括相应的代理，以用于协调所述遥测的收集和所述工作负荷在所述从节点之间的分配。
在示例37中，示例36的主题包括：其中，基于各个主可编排设备与至少一个从节点的配对来组织各个集群；其中，所述相应的代理协调所述工作负荷在所述各个集群中的分配。
在示例38中，示例36-37的主题包括：在多级分层结构的底层执行各个从节点的检测、发现和部署。
在示例39中，示例31-38的主题包括：从经组织的编排的组件中收集软件数据、硬件数据和网络数据，所述经组织的编排的组件包括所述传统组件和所述可编排组件；由编排服务器基于收集到的软件数据、硬件数据和网络数据执行监视；以及从所述编排服务器向所述经组织的编排的组件提供反馈和控制，以便响应于所述监视来控制所述经组织的编排。
在示例40中，示例1-39的主题包括：定义和部署用于所述软件定义的工业系统的自描述性控制应用和软件模块，其中所述自描述性控制应用包括多个自描述性可编排软件模块。
在示例41中，示例40的主题包括：创建模块清单以用于描述所述可编排软件模块的特性；基于所述可编排软件模块中可用特征的定义和连接来定义应用规范；定义所述可编排软件模块的操作的选项和替代；以及基于所述选项和替代来选择所述可编排软件模块。
在示例42中，示例41的主题包括在模拟的应用设置中仿真、评价所述可编排软件模块的操作，其中，基于所述可编排软件模块的选择是基于所述模拟的应用设置的结果。
在示例43中，示例42的主题包括：其中，用于模拟和评价所述可编排软件模块的操作的操作包括：使用应用规范和一个或多个模块清单来确定可用的应用和软件模块配置；通过特性控制器定义多个编排场景；用模拟器执行应用模块和具有(多个)定义的选项的至少一个替代应用模块，以便实现所述多个编排场景；基于硬件性能和用户输入，评价所述应用模块和所述至少一个替代应用模块的执行结果；以及为所述应用模块和所述至少一个替代应用模块的执行结果生成相应的得分。
在示例44中，示例42-43的主题包括：其中，与所述执行结果相关联的场景基于各自的得分被自动并入以用于在应用中使用。
在示例45中，示例1的主题包括：诸如在io转换器处，从现场设备(例如，传感器)接收数据；根据现场设备总线协议转换来自所述现场设备的数据；将转换后的数据发送到现场设备抽象总线；经由所述现场设备抽象总线从控制设备接收控制信号；以及基于所述控制信号将电信号发送至所述现场设备。
在示例46中，示例1的主题包括：诸如在传感器总线处经由多个对应的io转换器从多个现场设备(例如，传感器)接收数据；将所述数据发送到一个或多个控制功能；基于所述数据从所述一个或多个控制功能接收一个或多个控制信号，以及将所述一个或多个控制信号发送到所述多个io转换器中的各个io转换器。
在示例47中，示例46的主题包括：从io转换器模式控制器接收信息，并根据从所述io转换器模式控制器接收到的信息，促进将io转换器分配给现场设备。
在示例48中，示例1的主题包括：保存关于工业控制系统的多个警报的信息；从所述信息中分析所述多个警报的数据、上下文或警报配置；从所述信息确定警报流相似度；检测两个或多个警报处的警报事件；阻止发出所述两个或多个警报；为被阻止发出的所述两个或多个警报生成聚类的警报。
在示例49中，示例48的主题包括：建议更改所述多个警报中的一个或多个或建议新警报。
在示例50中，示例1的主题包括：管理新的闭环工作负荷算法的自主创建。
在示例51中，示例50的主题包括：执行所述新算法相对于当前过程(例如，工业控制系统过程)的质量或灵敏度评估。
在示例52中，示例50-51的主题包括：自主建立操作约束边界。
在示例53中，示例50-52的主题包括：相对于已有过程自主评估所述新算法的安全性。
在示例54中，示例50-53的主题包括：自主评估更广泛过程的价值。
在示例55中，示例50-54的主题包括：自主评估所述系统在控制环境中的部署可行性。
在示例56中，示例50-55的主题包括：物理上部署或监视新应用控制策略。
在示例57中，示例50-56的主题包括：将所述新算法集成到生命周期管理系统中。
在示例58中，示例50-57的主题包括：将所述新算法集成到报废处理中。
在示例59中，示例50-58的主题包括：按顺序执行示例51-58。
在示例60中，示例1的主题包括：诸如在编排服务器处确定工业控制系统(例如，环形部署)中的边缘控制节点的计算要求：接收激活一个或多个边缘控制节点的cpu的指示；以及向具有要激活的cpu的边缘控制节点发送经认证的激活码。
在示例61中，示例1的主题包括：在边缘控制节点处接收认证的激活码；在所述边缘控制节点处认证所述码以及使用微处理器(mcu)(例如，低性能处理器)来激活所述边缘控制节点的cpu。
在示例62中，示例60-61的主题包括：在由工业控制系统的编排系统布置的边缘控制节点的环形部署处执行示例60-61。
在示例63中，示例61的主题包括：在所述边缘控制节点处从所述编排服务器接收更新以停用cpu或将cpu置于低功率状态。
示例64是至少一种机器可读介质，包括指令，该指令在由计算系统执行时使得所述计算系统执行示例1-63中的任一示例。
示例65是一种装置，包括用于执行示例1-63中任意示例的相应装置。
示例66是一种软件定义的工业系统，包括相应设备和所述相应设备中的相应电路，其中所述相应电路被配置为用于执行示例1-63中任一示例的操作。
示例67是一种装置，包括电路，该电路被配置成用于执行如示例1-63中任一示例的操作。
在示例68中，示例67的主题包括：其中，所述装置是网关，其使得能够连接至适配的多个现场设备、其他设备网络或其他网络部署。
在示例69中，示例67-68的主题包括：其中，所述装置是可操作地耦合到至少一个传感器和至少一个执行器的设备。
在示例70中，示例67-69的主题包括：其中，所述装置是适于连接至多个现场设备的边缘控制节点设备。
在示例71中，示例67-70的主题包括：其中，所述装置是适于连接至多个现场设备的智能i/o控制器设备。
在示例72中，示例67-71的主题包括：其中，所述装置是适于连接至多个现场设备的基本i/o控制器设备。
在示例73中，示例67-72的主题包括：其中，所述装置是适于连接至多个网络系统的控制服务器计算系统。
在示例74中，示例67-73的主题包括：其中，所述装置是适于连接至多个联网的系统的控制处理节点计算系统。
示例75是一种网络系统，包括连接在雾或云网络拓扑内的各个设备，所述各个设备包括被配置为用于执行示例1-63中的任一示例的操作的电路。
在示例76中，示例75的主题包括：其中，所述各个设备经由实时服务总线连接。
在示例77中，示例75-76的主题包括：其中，所述网络拓扑包括经由冗余主机对的用于所述软件定义的工业系统的控制器、存储和计算功能。
在示例78中，示例75-77的主题包括：其中，所述网络拓扑包括经由单独物理主机的用于所述软件定义的工业系统的控制器、存储和计算功能。
示例79是一种工业控制系统的边缘控制节点，包括：输入/输出(io)子系统，其用于从现场设备接收信号并生成io数据；以及片上系统，包括：联网组件，其通信耦合到网络；微控制器(mcu)，其用于转换来自所述io子系统的所述io数据，并通过所述联网组件将转换后的数据经由网络发送到编排服务器；以及中央处理单元(cpu)，其最初处于非活动状态，用于响应于在所述边缘控制节点处通过所述联网组件从所述编排服务器接收到激活信号而变为激活状态。
在示例80中，示例79的主题包括：其中，所述cpu的所述激活状态包括低功率模式和高功率模式。
在示例81中，示例79-80的主题包括：其中，所述cpu还被配置为用于在经过一段时间的所述激活状态之后，从所述编排服务器接收去激活信号，并且作为响应，返回到所述非活动状态。
在示例82中，示例79-81的主题包括：其中，所述边缘控制节点是所述工业控制系统中的多个边缘控制节点之一，所述多个边缘控制节点包括在所述cpu被激活之后具有非活动的cpu的至少一个边缘控制节点。
在示例83中，示例79-82的主题包括：其中，所述cpu基于编排服务器确定该cpu将被激活以满足针对工业控制系统的控制策略而被激活。
在示例84中，示例79-83的主题包括，其中，所述联网组件是时间敏感的网络以太网交换机。
在示例85中，示例79-84的主题包括：其中，所述网络具有环形拓扑，所述环形拓扑具有将所述网络连接至所述编排服务器的桥设备。
在示例86中，示例79-85的主题包括：其中，在所述cpu处直接从所述mcu接收所述激活信号。
在示例87中，示例79-86的主题包括：其中，所述cpu还用于从所述编排服务器接收处理指令，所述cpu用于在处于所述激活状态时执行所述处理指令。
示例88是至少一种非瞬态机器可读介质，其包括指令，当由编排服务器的处理器执行该指令时，使得所述处理器执行以下操作：接收输入/输出(10)数据，所述io数据经由将所述编排服务器连接到边缘控制节点的桥被接收，其中所述io数据在所述边缘控制节点的微控制器(mcu)处被从在io子系统处生成的数据转换为由联网组件发送的数据包；向所述边缘控制节点发送经认证的激活码，以便激活所述边缘控制节点的中央处理单元(cpu)，其中，所述cpu最初被置于未激活状态；以及将处理指令发送到所述cpu以用于执行。
在示例89中，示例88的主题包括：其中，所述操作还使所述处理器确定边缘控制节点在包括所述边缘控制节点的工业控制系统中的计算要求，并且其中，所述cpu基于所述编排服务器确定激活所述cpu满足针对所述工业控制系统的控制策略而被激活。
在示例90中，示例88-89的主题包括：其中，所述操作还使处理器接收指示以激活所述工业控制系统中的所述边缘控制节点的所述cpu。
在示例91中，示例88-90的主题包括：其中，在激活所述cpu之前，由所述mcu对经认证的激活码进行认证
在示例92中，示例88-91的主题包括：其中，所述操作还使所述处理器将来自所述编排服务器的去激活码发送到所述cpu以便去激活所述cpu。
在示例93中，示例88-92的主题包括：其中，所述边缘控制节点具有环形拓扑网络，所述环形拓扑网络具有将所述网络连接至所述编排服务器的桥设备。
示例94是一种工业控制系统，包括：环形网络，其包括多个边缘控制节点；编排服务器；桥，其将所述编排服务器连接到所述环形网络；并且其中所述多个边缘控制节点包括，第一边缘控制节点，包括：片上系统，其包括：微控制器(mcu)，用于转换来自io子系统的输入/输出(io)数据，并通过联网组件将转换后的数据通过所述桥发送到所述编排服务器；以及处理器，其处于初始未活动状态，用于：从所述编排服务器接收激活信号；以及响应于接收到所述激活信号而变更为激活状态。
在示例95中，示例94的主题包括：其中，所述处理器还被配置为用于在经过一段时间的所述激活状态之后，从所述编排服务器接收去激活信号，并且作为响应，返回到所述非活动状态。
在示例96中，示例94-95的主题包括：其中，所述处理器基于编排服务器确定该处理器满足针对所述工业控制系统的控制策略而被激活。
在示例97中，示例94-96的主题包括：其中，在所述处理器处直接从所述mcu接收所述激活信号。
在示例98中，示例94-示例97的主题包括，其中，所述多个边缘控制节点包括第二边缘节点，其中第二处理器在所述第一边缘控制节点的处理器被激活之后保持非活动状态。
在示例99中，示例94-98的主题包括：其中，所述编排服务器还被配置为用于将处理指令发送到所述处理器以用于执行。
在示例100中，示例94-99的主题包括：其中，所述处理器是中央处理单元(cpu)。
示例101是至少一种机器可读介质，其包括指令，该指令在由处理电路执行时，使得所述处理电路执行操作以实现示例79-100中的任一示例。
示例102是一种装置，包括用于实现示例79-100中的任一示例的装置。
示例103是一种系统，用于实现示例79-100中的任一示例。
示例104是一种用于实现示例79-100中的任一示例的方法。
示例105是一种装置，包括处理电路，所述处理电路适于：标识可用软件模块的操作方面，所述可用软件模块适于在控制系统环境中执行功能操作；从模块清单中标识操作特性，其中所述操作特性定义供所述可用软件模块执行控制系统应用的环境；基于所述可用软件模块的所标识的操作方面以及从所述模块清单中标识出的操作特性，选择所述可用软件模块中的软件模块；以及导致在所述控制系统环境中执行所选择的软件模块，其中所述执行根据所述控制系统应用的应用规范来发生。
在示例106中，示例105的主题包括：其中，所述可用软件模块的所述操作方面涉及以下中的一个或多个：通信接口、起始参数、平台要求、依赖性、部署要求或签名。
在示例107中，示例105-106的主题包括：所述处理电路还适于：基于所述操作特性和所选择的软件模块，生成用于控制系统应用的所述应用规范；其中所述应用规范定义所选择的软件模块的控制参数的值。
在示例108中，示例107的主题包括：其中，所述应用规范指示从所选择的软件模块到第二所选择的软件模块的连接。
在示例109中，示例105-108的主题包括：所述处理电路还适于：使用至少两种不同的硬件架构评价所选择的软件模块在所述控制系统环境中的执行；以及对利用所述至少两种不同硬件架构执行的操作进行效率测量。
在示例110中，示例105-109的主题包括：其中，所述控制系统应用和各个软件模块被显示为图形用户界面中的视觉表示，其中所述视觉表示用于建立所述控制系统应用内的所述软件模块的一个或多个输入或输出的关系，其中所述软件模块的所述输入或输出包括使用以下中的一个或多个：传感器、执行器或控制器。
在示例111中，示例105-110的主题包括：其中，所述设备是编排设备，其中所述编排设备可操作地耦合至所述控制系统环境中执行软件模块的多个执行设备，并且其中经由至少一个执行设备执行所选择的软件模块影响所述控制系统环境中一个或多个控制设备的功能操作。
在示例112中，示例111的主题包括：其中，所述处理电路还适于：利用所述控制系统环境中的编排控制策略来协调所选择的软件模块的执行。
在示例113中，示例105-112的主题包括：其中，所述处理电路还适于：选择多个软件模块，所述多个软件模块包括所述软件模块的选择；以及根据所述操作特性将所述多个软件模块彼此连接。
示例114是一种方法，包括：标识可用软件模块的操作方面，所述可用软件模块适于在控制系统环境中执行功能操作；从模块清单中标识操作特性，其中所述操作特性定义供所述可用软件模块执行控制系统应用的环境；基于所述可用软件模块的所标识的操作方面以及从所述模块清单中标识出的操作特性，选择所述可用软件模块中的软件模块；以及导致在所述控制系统环境中执行所选择的软件模块，其中所述执行根据所述控制系统应用的应用规范来发生。
在示例115中，示例114的主题包括：其中，所述可用软件模块的所述操作方面涉及以下中的一个或多个：通信接口、起始参数、平台要求、依赖性、部署要求或签名。
在示例116中，示例114-115的主题包括：基于所述操作特性和所选择的软件模块，生成用于控制系统应用的所述应用规范；其中所述应用规范定义所选择的软件模块的控制参数的值，并且其中所述应用规范指示从所选择的软件模块到第二所选择的软件模块的连接。
在示例117中，示例114-116的主题包括：使用至少两种不同的硬件架构评价所选择的软件模块在控制系统环境中的执行；以及标识利用所述至少两种不同硬件架构执行的操作的效率测量。
在示例118中，示例114-117的主题包括：其中，所述控制系统应用和各个软件模块被显示为图形用户界面中的视觉表示，其中所述视觉表示用于建立所述控制系统应用内的所述软件模块的一个或多个输入或输出的关系，其中所述软件模块的所述输入或输出包括使用以下中的一个或多个：传感器、执行器或控制器。
在示例119中，示例114-118的主题包括：其中，所述方法由编排设备执行，其中所述编排设备可操作地耦合至所述控制系统环境中执行软件模块的多个执行设备，并且其中经由至少一个执行设备执行所选择的软件模块影响所述控制系统环境中一个或多个控制设备的功能操作。
在示例120中，示例119的主题包括：利用所述控制系统环境中的编排控制策略来协调所选择的软件模块的执行。
在示例121中，示例119-120的主题包括：选择用于在所述控制系统环境中使用的多个软件模块，所述多个软件模块包括对所述软件模块的选择；以及根据所述操作特性，将所述多个软件模块相互连接。
示例122是至少一种非瞬态机器可读存储介质，其包括指令，当由设备的处理电路执行该指令时，使得所述处理电路执行多个操作，所述多个操作包括：标识可用软件模块的操作方面，所述可用软件模块适于在控制系统环境中执行功能操作；从模块清单中标识操作特性，其中所述操作特性定义供所述可用软件模块执行控制系统应用的环境；基于所述可用软件模块的所标识的操作方面以及从所述模块清单中标识出的操作特性，选择所述可用软件模块中的软件模块；以及导致在所述控制系统环境中执行所选择的软件模块，其中所述执行根据所述控制系统应用的应用规范来发生。
在示例123中，示例122的主题包括：其中，所述可用软件模块的所述操作方面涉及以下中的一个或多个：通信接口、起始参数、平台要求、依赖性、部署要求或签名。
示例124中，示例122-123的主题包括，所述操作还包括：基于所述操作特性和所选择的软件模块，生成用于控制系统应用的所述应用规范；其中所述应用规范定义所选择的软件模块的控制参数的值，并且其中所述应用规范指示从所选择的软件模块到第二所选择的软件模块的连接。
示例125中，示例122-124的主题包括，所述操作还包括：使用至少两种不同的硬件架构评价所选择的软件模块在所述控制系统环境中的执行；以及对利用所述至少两种不同硬件架构执行的操作进行效率测量。
在示例126中，示例122-125的主题包括：其中，所述控制系统应用和各个软件模块被显示为图形用户界面中的视觉表示，其中所述视觉表示用于建立所述控制系统应用内的所述软件模块的一个或多个输入或输出的关系，其中所述软件模块的所述输入或输出包括使用以下中的一个或多个：传感器、执行器或控制器。
在示例127中，示例122-126的主题包括：其中，所述多个操作由编排设备执行，其中所述编排设备可操作地耦合至所述控制系统环境中执行软件模块的多个执行设备，并且其中经由至少一个执行设备执行所选择的软件模块影响所述控制系统环境中一个或多个控制设备的功能操作。
示例128中，示例127的主题包括，所述操作还包括：利用所述控制系统环境中的编排控制策略来协调所选择的软件模块的执行。
示例129中，示例127-128的主题包括，所述操作还包括：选择用于在所述控制系统环境中使用的多个软件模块，所述多个软件模块包括所述软件模块的选择；以及根据所述操作特性将所述多个软件模块彼此连接。
示例130是至少一种机器可读介质，其包括指令，该指令在由处理电路执行时，使得所述处理电路执行操作以实现示例105-129中的任一示例。
示例131是一种装置，包括用于实现示例105-129中的任一示例的装置。
示例132是一种系统，用于实现示例105-129中的任一示例。
示例133是一种用于实现示例105-129中的任一示例的方法。
示例134是一种运行应用的分布式节点的经标牌系统，所述经编排系统包括：第一节点，其执行具有第一输出的第一模块；以及第二节点，其执行第二模块，所述第二模块使用所述第一输出作为输入，并且将第二输出提供给在第三节点上执行的第三模块；其中，响应于检测到所述第二节点的故障，所述第一节点和所述第三节点被配置成用于协调以确定用于重新部署所述第二模块的替换节点。
在示例135中，示例134的主题包括：其中，所述替换节点是被预配置成用于接收所述第一输出并操作所述第二模块的冗余节点。
在示例136中，示例135的主题包括：其中，所述冗余节点不连接以向任何节点提供输出，直到所述冗余节点作为所述替换节点来操作之后。
在示例137中，示例135-136的主题包括：其中，所述第二节点被配置成用于向所述冗余节点周期性地发送关于所述第二模块的参数和状态信息。
在示例138中，示例135-137的主题包括：其中，响应于所述冗余节点发生故障，第二冗余节点被指定为所述替换节点。
在示例139中，示例134-138的主题包括：其中，所述第一节点被配置成用于在所述第一输出被生成时保存所述第二模块的冗余状态。
在示例140中，示例134-139的主题包括：其中，在协调时，所述第一节点和所述第三节点被配置成用于确定连接到所述第二节点的一组节点。
在示例141中，示例134-140的主题包括：其中，所述替换节点被配置成用于连接到所述第一节点以接收来自所述第一模块的输出，并且连接到所述第三节点以将来自所述第二模块的输出提供给所述第三模块。
在示例142中，示例134-141的主题包括：其中，所述第一节点、第二节点和第三节点上的所述第一模块、第二模块和第三模块的配置最初由编排服务器生成，并且其中所述编排服务器被配置成用于与所述第一节点、第二节点和第三节点断开连接。
在示例143中，示例134-142的主题包括：其中，所述第二节点被实现在虚拟机上，并且其中基于所述第二节点在所述虚拟机上的映像，在所述替换节点中实例化所述第二模块。
在示例144中，示例134-143的主题包括：其中，使用领导者选举算法选择所述第一节点作为领导者节点。
示例145是一种使用经编排系统的分布式节点运行应用的方法，该方法包括：在第一节点上执行第一模块，所述第一模块具有第一输出；在第二节点上执行第二模块，所述第二模块使用所述第一输出作为输入；将来自所述第二模块的第二输出提供给在第三节点上执行的第三模块；以及，响应于检测到所述第二节点的故障，通过在所述第一节点和所述第三节点之间进行协调来确定用于重新部署所述第二模块的替换节点。
在示例146中，示例145的主题包括：其中，确定所述替换节点包括标识被预配置成用于接收所述第一输出并操作所述第二模块的冗余节点。
在示例147中，示例146的主题包括：其中，所述冗余节点不连接以向任何节点提供输出，直到所述冗余节点作为所述替换节点来操作之后。
在示例148中，示例146-147的主题包括：从所述第二节点向所述冗余节点周期性地发送有关所述第二模块的参数和状态信息。
在示例149中，示例146-148的主题包括：其中，响应于所述冗余节点发生故障，第二冗余节点被指定为所述替换节点。
在示例150中，示例145-149的主题包括：在所述第一节点处，在所述第一输出被生成时保存所述第二模块的冗余状态。
在示例151中，示例145-150的主题包括：其中，确定所述替换节点包括确定连接到所述第二节点的一组节点。
在示例152中，示例149-151的主题包括：将所述替换节点连接到所述第一节点以接收来自所述第一模块的输出以及所述替换节点连接到所述第三节点以将来自所述第二模块的输出提供给所述第三模块。
在示例153中，示例145-152的主题包括：最初使用编排服务器生成所述第一节点、第二节点和第三节点上的所述第一模块、第二模块和第三模块的配置，并且还包括在所述第二节点故障前使所述编排服务器与所述第一节点、第二节点和第三节点断开连接。
在示例154中，示例145-153的主题包括：在虚拟机上实现所述第二节点，并且还包括基于所述第二节点在所述虚拟机上的映像，在所述替换节点中实例化所述第二模块。
在示例155中，示例145-154的主题包括：使用领导者选举算法选择所述第一节点作为领导者节点。
示例156是至少一种机器可读介质，其包括指令，该指令在由处理电路执行时，使得所述处理电路执行操作以实现示例134-155中的任一示例。
示例157是一种装置，包括用于实现示例134-155中的任一示例的装置。
示例158是一种系统，用于实现示例134-155中的任一示例。
示例159是一种用于实现示例134-155中的任一示例的方法。
- 还没有人留言评论。精彩留言会获得点赞！