具体实施方式

图1是图示包含本发明的示例实施例的分布式计算机网络100的简化框图。计算机网络100包括经由多个通信链路128耦合到通信网络124的多个客户端系统113、116和119以及服务器系统122。通信网络124提供用于允许分布式网络100的各种组件相互通信和交换信息的机制。

通信网络124本身可以由许多互连的计算机系统和通信链路组成。通信链路128可以包括硬线链路、光链路、卫星或其他无线通信链路、波传播链路或用于信息通信的任何其他机制。通信链路128可以包括DSL、电缆、以太网或其他硬线链路、无源或有源光链路、3G、3.5G、4G和其他移动性、卫星或其他无线通信链路、波传播链路或用于信息通信的任何其他机制。

各种通信协议可用于促进图1中所示的各种系统之间的通信。通信协议可包括VLAN、MPLS、TCP/IP、隧道、HTTP和相关协议、无线应用协议(WAP)、供应商特定协议、自定义协议等。虽然在一个实施例中，通信网络124包括因特网，但在其他实施例中，通信网络124可以包括任何合适的通信网络，包括局域网(LAN)、广域网(WAN)、无线网络、内联网、专用网络、公共网络、交换网络或这些的组合等。

应当理解，分布式计算机网络100仅仅是结合本发明的示例实施例的说明，并不限制如权利要求中所述的本发明的范围。本领域的普通技术人员将认识到其他变化、修改和替代。例如，一个以上的服务器系统122可以连接到通信网络124。作为另一示例，多个客户端系统113、116和119可以通过接入提供商(未示出)或通过一些其他服务器系统连接到通信网络124。

客户端系统(例如客户端系统113、116和119)通常从提供信息的服务器系统(例如服务器系统122)请求信息。为此，服务器系统通常比客户端系统具有更多的计算和存储容量。然而，取决于特定计算机系统是请求信息还是提供信息，计算机系统可以同时充当客户端和服务器。此外，虽然本发明的各方面已经在客户端-服务器环境的上下文中进行了描述，但显然本发明也可以体现在独立的计算机系统中。

服务器系统122负责从客户端系统113、116和119接收信息请求，执行满足请求所需的处理，并将与请求对应的结果转发回请求客户端系统。满足请求所需的处理可以由服务器系统122执行，或者可以替代地委托给连接到通信网络124的其他服务器。

客户端系统113、116和119使用户能够访问和查询服务器系统122存储的信息。在特定示例实施例中，客户端系统可以作为独立应用(例如桌面应用或移动智能手机或平板应用)运行。在另一个示例实施例中，在客户端系统上执行的“网络浏览器”应用可以使用户能够选择、访问、检索或查询由服务器系统122存储的信息。网络浏览器的示例包括由Microsoft公司提供的Internet Explorer浏览器程序、Mozilla提供的Firefox浏览器、Google提供的Chrome浏览器、Apple提供的Safari浏览器等。因此可以理解，客户端系统113、115和119以及服务器系统122可以包括硬件、软件或固件、或者这些组件的组合。

在客户端-服务器分布式网络环境中，一些资源(例如，文件、音乐、视频或数据)可以存储在客户端，而其他资源可以存储在网络中的其他地方(例如服务器)或从其传送，并且可以通过网络(例如，因特网)访问。因此，用户的数据可以远离用户的位置而远程存储在网络或“云”中。例如，用户可以使用本地客户端设备来处理远程存储在云(例如，服务器)上的文档。客户端设备上的本地数据可以与存储在云中的远程数据同步。

图2示出了本发明的示例性客户端或服务器系统，包括计算机工作站系统201。在示例实施例中，用户可以通过计算机系统201与分布式计算机网络接口。计算机系统201可以包括外壳207(也可以称为系统单元、机柜或壳)，以及一个或多个外围设备，包括例如监视器203、屏幕205、键盘或其他人类输入设备209、以及鼠标或其他点选设备211。鼠标211可以具有一个或多个按钮，例如鼠标按钮213。

应当理解，本发明不限于特定形状因子(例如，台式计算机形状因子)的任何计算设备，并且示例客户端和服务器系统可以包括并使用所有类型的各种形状因子的计算设备。例如，用户可以与包括任何类型的计算设备的客户端或服务器系统交互，包括智能手机、个人计算机、膝上型计算机、电子平板设备、全球定位系统(GPS)接收器、便携式媒体播放器、个人数字助理(PDA)、其他网络接入设备和其他能够接收或传输数据的处理设备。

例如，在具体实现中，客户端设备可以是智能手机或平板设备，例如Apple iPhone(例如Apple iPhone 6)、Apple iPad(例如Apple iPad或Apple iPad mini)、Apple iPod(例如Apple iPod Touch)、Samsung Galaxy产品(例如Galaxy S系列产品或Galaxy Note系列产品)、Google Nexus设备(例如Google Nexus 6、Google Nexus 7或Google Nexus 9)或Microsoft设备(例如，Microsoft Surface平板)。通常，智能电话包括可通过触摸屏显示器访问的电话部分(和相关联的无线电话)和计算机部分。此外，通常有非易失性存储器来存储电话部分(例如联系人和电话号码)和计算机部分(例如，包括浏览器、图片、游戏、视频和音乐的应用程序)的数据。智能手机通常还包括用于拍摄照片和视频的相机(例如，前置相机或后置相机，或两者都被包括)。例如，智能手机或平板可用于拍摄可以流送到一个或多个其他设备的实时视频。

外壳207容纳熟悉的计算机组件(其中一些未示出)，例如处理器、存储器、大容量存储设备217等。大容量存储设备217可以包括大容量盘驱动器、软盘、磁盘、光盘、磁光盘、固定盘、硬盘、CD-ROM、可记录CD、DVD、可记录DVD(例如，DVD-R、DVD+R、DVD-RW、DVD+RW、HD-DVD或蓝光光盘)、闪存和其他非易失性固态存储装置(例如，USB闪存驱动器或固态驱动器(SSD))、电池备份的易失性存储器、磁带存储、阅读器和其他类似的介质、以及这些的组合。

结合本发明或其方面的计算机实现或计算机可执行版本或计算机程序产品可以使用计算机可读介质体现、存储在计算机可读介质上或与计算机可读介质相关联。计算机可读介质可包括参与向一个或多个处理器提供指令以供执行的任何介质。这种介质可以采用多种形式，包括但不限于非易失性、易失性和传输介质。非易失性介质可包括例如闪速存储器、或光盘或磁盘。易失性介质包括静态或动态存储器，例如高速缓存存储器或RAM。传输介质可以包括例如同轴电缆、铜线、光纤线和布置在总线中的线。传输介质也可以采用电磁波、射频、声波或光波的形式，例如在无线电波和红外数据通信期间产生的那些。

例如，包含本发明或其方面的软件的二进制、机器可执行版本可被存储或驻留在RAM或高速缓存存储器中或大容量存储设备217上。软件的源代码也可被存储或驻留在大容量存储设备217(例如，硬盘、磁盘、磁带或CD-ROM)上。作为进一步的示例，结合本发明或其方面的代码可以通过电线、无线电波或通过诸如因特网之类的网络传输。

图3示出了示例计算机系统201的系统框图，该示例计算机系统201可以用于执行结合本发明或其方面的软件。如图2所示，计算机系统201包括监视器203、键盘209和大容量存储设备217。计算机系统201还包括子系统，例如中央处理器302、系统存储器304、输入/输出(I/O)控制器306、显示适配器308、串行端口312(也可以是通用串行总线(USB)、并行数据或其他数据端口)、网络接口318和扬声器320。本发明还可以与具有附加或更少子系统的计算机系统一起使用。例如，计算机系统可包括多于一个处理器302(即，多处理器系统)或可包括高速缓存存储器或这些的组合。

双头箭头322表示计算机系统201的系统总线体系结构。然而，该箭头表示用于链接计算机系统的各种子系统的任何互连方案。例如，扬声器320可以通过端口连接到其他子系统或具有到中央处理器302的内部直接连接。处理器302可以包括多个处理器或多核处理器，其可以允许信息的并行处理。计算机系统201只是适用于本发明的计算机系统的示例。适用于本发明的子系统的其他配置对于本领域的普通技术人员来说将是显而易见的。

包含本发明或其方面的计算机软件和软件产品可以用各种合适的编程语言中的任一种编写，例如C、C++、C#、Pascal、Fortran、Perl、Matlab(来自MathWorks，www.mathworks.com)、SAS、SPSS、JavaScript、AJAX、Java、Python、Erlang和Ruby onRails，并且可以以这些或其他形式部署到各种计算平台，例如XML、PMML或FogHornSystems,Inc.的或这些的组合。计算机软件和软件产品可以包括一个或多个独立的应用，并且这些应用可以具有数据输入、数据显示或数据显示模块或这些的组合。替代地，计算机软件和软件产品可以包括可以实例化为分布式对象的类。计算机软件和软件产品还可以包括组件软件，例如Java Beans(来自Oracle Corporation)或Enterprise JavaBeans(来自Oracle Corporation的EJB)。

任何合适的操作系统都可以与计算机系统一起使用，包括Microsoft系列系统(例如，Windows 95、98、Me、Windows NT、Windows 2000、Windows XP、Windows XP x64 Edition、Windows Vista、Windows 7、Windows 8、Windows 10、WindowsCE、Windows Mobile、Windows RT)、Symbian OS、Tizen、Linux、HP-UX、UNIX、Sun OS、Solaris、Mac OS X、Apple iOS、Android、Alpha OS、AIX、IRIX32或IRIX64中的一种。也可以使用其他操作系统。(Microsoft Windows是Microsoft Corporation的商标。)

此外，计算机系统可以连接到网络并且可以使用网络连接到其他计算机。网络可以包括内联网、互联网或因特网等中的一个或多个。网络还可以包括有线网络(例如，使用铜线)、电话网络、分组网络、光网络(例如，使用光纤)或无线网络、或者这些的任何组合。例如，数据、信号和其他信息可以在计算机和其他计算机或包含本发明或其方面的系统的组件(或步骤)之间通过无线网络使用诸如Wi-Fi(IEEE标准802.11、802.11a、802.11b、802.11e、802.11g、802.11i、802.11n、802.11ac和802.11ad，仅举几个示例)、近场通信(NFC)、射频识别(RFID)、移动或蜂窝无线(例如，2G、3G、4G、3GPP LTE、WiMAX、LTE、LTEAdvanced、Flash-OFDM、HIPERMAN、iBurst、EDGE Evolution、UMTS、UMTS-TDD、1xRDD和EV-DO)或其他的协议无线传输或传递。

在示例实施例中，利用在计算机工作站系统上执行的网络浏览器，用户可以通过诸如因特网的网络访问万维网(WWW)上的系统。网络浏览器可用于下载各种格式的网页或其他内容，包括HTML、XML、文本、PDF和postscript，并可用于将信息上传到系统的其他部分。网络浏览器可以使用统一资源标识符(URL)来标识网络上的资源并且在网络上传输文件时使用超文本传输协议(HTTP)。

在其他实现中，用户可以通过本机和非本机应用中的一个或两个来访问系统。本机应用本地安装在特定计算系统上，并且特定于操作系统或该计算系统的一个或多个硬件设备、或这些的组合。这些应用(有时也称为“app”)可以通过直接的互联网升级补丁机制或通过应用商店(例如，Apple iTunes和App商店、Google Play商店、Windows Phone商店和黑莓App世界商店)进行更新(例如，定期更新)。

该系统还可以通过独立于平台的非本机应用访问。例如，用户或客户端可以通过来自一个或多个服务器的网络应用访问系统，使用与服务器或多个服务器的网络连接在用户或客户端的网络浏览器中加载网络应用。例如，网络应用可以通过网络浏览器通过因特网从应用服务器下载。非本机应用也可以从其他来源获得，例如从磁盘获得。

边缘计算平台

图4示出了示例改进的智能边缘计算平台406的框图。预计边缘计算平台将通常在传感器409和云412之间的边缘网关或等效物上运行。应当理解虽然边缘计算平台可以包括独立平台，但它也可以嵌入一个或多个其他边缘组件、子系统、设备、机器等或与之结合。还应当理解，边缘计算平台及其各个组件可以以软件、硬件、固件、嵌入式硬件、独立硬件、专用硬件或这些的任何组合来实现。更进一步，示例平台可以跨云、中型计算服务器和小型化计算服务器以不同的形状因子部署。例如，平台可以托管在计算基础设施上，计算基础设施包括例如并置在包含传感器的网络中的中型服务器(例如，双核处理器和4GB的存储器)或小型化服务器(例如，单核处理器核并具有小于1GB的存储器)。优选地，无论实现边缘计算平台的计算环境如何，平台上的边缘应用(下文进一步描述)可以使用相同的应用程序接口(API)集来完成与企业本地物理运营相关的数据管理、数据分析和管理任务。

显而易见，在分布式网络IoT环境中，优选的是智能边缘计算平台位于或与远程云站点412相比相对靠近本地网络或具有物理传感器409以及生成要处理和分析的数据的其他设备以及要被控制的设备和系统的网络的边缘。通过在更靠近本地网络的物理传感器、设备和控制系统的边缘托管高性能实时数据处理、数据分析和异构应用，智能边缘计算平台可以实时有效地从传感器和其他数据中生成边缘智能。边缘智能可用于完成实时闭环设备控制、管理和优化。例如，在工业物联网(IIoT)环境中，这可以有效地带来大数据和现场实时处理能力的优势，这对制造、石油和天然气、电力和水、交通、矿业、可再生能源、智慧城市和其他领域的工业客户来说是无价的

图4中所示的传感器409可以是例如多个物理传感器，它们连接在企业的一个或多个物理操作的本地网络或多个互连本地网络中。在其他示例实施例中，各种传感器409可以分布在广泛区域的各种网络中，并且边缘平台406的应用可以访问来自一些或所有传感器的数据，并基于来自传感器数据的数据和从中得出的分析来提供实时响应和消息。应当理解，在本文的整个描述中，对“传感器”的引用旨在不仅包括传统传感器，例如压力和温度传感器，而且还包括能够生成连续数据流的其他设备、逻辑和换能器，包括例如摄像机、音频麦克风等。

云412可以包括例如远程数据中心、远程计算或远程存储站点、或这些的组合。边缘计算平台用于从数据得出边缘智能，其中部分或全部数据可能由传感器或企业的本地网络或互连网络中的其他数据生成源生成。边缘智能提供重要信息，例如可用于管理、维护和优化IIoT环境中工业机器和其他工业组件的性能的信息。

示例边缘网关平台406的组件包括以下：摄取组件421、富集组件425、复杂事件处理(CEP)引擎429、应用432、分析组件435和传输组件438。云可以包括边缘供应和编排组件443以及云和边缘分析和应用可移植性组件446。

数据摄取组件421在边缘层的多个网络接口上接收多个数据流，并且优选地根据各种已建立的数据摄取协议(例如，OPC-UA、Modbus、MQTT、DDS等)以及其他合适的数据传输协议来识别和接受传感器和其他IoT数据。此外，摄取组件应该能够结合自定义协议适配器以识别自定义协议，例如由特定传感器制造商或特定本地网络的所有者或运营商定义的专有协议。下面描述了摄取组件的更多细节。

富集组件425接收摄取组件421摄取的数据并对其进行丰富或预处理。例如，富集组件可以在摄取的数据流被提供给边缘智能组件之前，对此数据进行数据解码、数据错误检测和纠正、越界数据检测和处理、丢失数据检测和处理、元数据修饰、数据规范化或其他数据处理或这些的组合中的一个或多个以及任意组合。对于音频和视频数据，富集还可包括图像大小调整、打时间戳、颜色到灰度转换、上采样和下采样、打包和解包、某些编解码器的应用等。优选地，优选通过向摄取的数据流应用选定的表达，对其实时地执行富集处理。下面更详细地描述了例如，可以将相同或不同的富集处理应用于各个数据流，并且富集组件也可以混合或以其他方式组合多个传入流以创建额外的富集数据流以供各种边缘应用使用。

边缘应用432优选地驻留在智能边缘平台406本身上并在其上执行。然而，如下文进一步描述的，优选地，应用自包含它们执行所需的所有资源，以便它们也可以驻留在具有潜在不同资源的其他计算平台(例如云中的远程计算平台或者本地或其他网络中的计算平台，如果需要的话)上并在其上执行。应用可以访问本地网络中生成的传感器和IoT设备数据，这些数据已经由摄取组件421摄取并被富集组件425富集。应用可以实时地访问传感器流数据，或者可以访问已在批处理模式下聚合的传感器数据。

应用可以由复杂事件处理(CEP)引擎429(也称为分析引擎)触发或接收来自复杂事件处理(CEP)引擎429的输入，或两者都进行，该引擎优选地适于在低占用空间机器上运行。应用还可以访问分析组件435以获取或贡献(或两者都进行)从传感器数据和其他数据导出或与传感器数据和其他数据相关的智能或其他分析信息或这两者。

摄取并富集的传感器数据可以被聚合并存储在边缘平台406上的本地存储库中，这在下面进一步描述。可以调用传输组件438以将摄取并富集的传感器数据传输或发布到远程云412以用于离线存储、处理或分析、或这些的组合。然而，如前所述，许多工业环境和设备缺乏因特网连接。此外，即使有因特网连接，产生的大量数据也很容易超过可用带宽，或者成本太高而无法发送到云端。此外，当数据上传到云端、在数据中心进行处理并将结果传回边缘时，在本地网络中采取动作(数据已表明这是必要的或期望的)可能为时已晚。然而，如果边缘平台和云之间的因特网或其他连接可用，那么将传感器数据从本地网络传输到云的能力对于开发、训练和评估机器学习模型和应用非常有用，如本文进一步讨论的。

边缘平台的数据分析组件包括复杂事件处理(CEP)引擎429和分析组件435。分析组件包括用于提供数据分析、流处理或这两者、数据聚合、规则定义和应用、以及边缘处对机器学习工作流的定义、选择和应用的表达语言。复杂事件处理(CEP)引擎429也被称为分析引擎并且优选地包括高度小型化和强大的领域特定语言(DSL)执行引擎。DSL优选地包括实时表达语言，例如FogHorn Systems,Inc.(FogHorn)的表达语言，其适于并适合于实时地处理数据流并从中导出分析和智能。除了可以从FogHorn获得之外，语言的各个方面以及与之相关的各种工具(例如编译器和调试器)在FogHorn的美国专利申请15/250,720(现在的美国专利10,007,513)；15/467,306；15/467,313和15/467,318(现在的美国专利10,127,022)中进行了描述，这些申请通过引用并入。DSL用于表达规则和分析功能，这些功能可由引擎针对潜在的大量传入传感器数据流执行。来自执行的DSL表达的输出可以对应用可用并且可以立即被应用使用或者以其他方式实时地根据传感器数据指示的本地网络中的状况或发生采取动作、提供警告等。这可以防止代价高昂的机器故障或停机，并实时地提高工业运营和流程的效率和安全性，而无需等待远程云站点处数据的处理和分析。

如图4所示，云412可以包括云/边缘分析和应用可移植性446功能。此外，如下文进一步详细描述的，智能边缘平台可以包括用于在边缘平台上开发和部署异构应用以及促进应用在边缘和云之间的动态移动的能力。因此，可以在分布式网络系统的边缘平台上、云中或其他边缘平台上或这些的组合上开发应用。应用可以部署在开发它们的边缘平台上、云中或其他边缘平台上。在这方面，应用优选使用诸如容器化的技术来开发，这些技术使它们能够跨云和边缘动态移动。可以在云和边缘之间开发和部署用于对边缘平台的摄取的富集数据执行的许多不同的应用，包括高级机器学习(ML)应用和模型。下文更详细描述的应用商店也可用于促进将容器化应用部署到边缘。

如上所述，智能边缘平台在IoT和IIoT设备所在的本地网络边缘结合了硬件和软件组件。边缘软件堆栈包括可以在边缘上和云中运行的软件服务的组合。作为摄取组件421的一部分，边缘软件堆栈的一部分提供负责从传感器和网络设备(例如工业机器)摄取流数据的服务。如下文进一步描述的，数据被摄取到高速数据总线上，从该高速数据总线，数据可以通过由CEP组件429执行的用户定义的分析表达进行操作，以获得见解、控制并优化网络设备、提供通知或警告、或这些的组合等。

边缘软件堆栈服务还可以包括本地时间序列数据库，其中传感器和其他数据可以在本地聚合，应用可以从中进行基于时间的传感器数据查询。服务还可以包括作为传输组件438的一部分的发布功能，用于将这样的聚合数据发送到云，在云中聚合数据可以用于创建、训练、评估和更新机器学习模型等等。

边缘软件服务还可以包括多语言软件开发工具包(SDK)，用于开发移动自包含边缘应用，这些应用可以在边缘平台上、云中或上述两者中执行。优选地，开发的应用能够以流模式和批处理模式消费数据。

同样如图4所示，云412可以包括边缘供应和编排443功能。此类功能结合了由微服务支持的远程管理控制台，以远程管理与云通信的一个或多个边缘计算平台的各种硬件和软件方面。使用此功能，可以通过远程管理控制台配置、部署、管理和监控多个不同的边缘安装。应当理解，虽然边缘供应和编排443在图4中被示为包括云412的一部分，但是可以将相同的远程管理和控制功能替代地或另外合并到边缘计算平台所连接的本地网络中的云，或合并到与边缘计算平台通信的任何其他网络或计算平台。

相应地，边缘软件服务还可以包括管理服务和具有用户界面(UI)的管理控制台。管理服务可以驻留并运行在边缘平台上、云中、本地计算环境上或这些的组合。管理服务提供远程部署、设置、配置和管理边缘平台和组件，包括资源供应。管理服务还可以管理例如开发、部署和配置应用和分析表达。例如，管理服务可以使用称为Docker(www.docker.com)的应用来促进容器化分析表达和应用的开发和向边缘平台的部署。管理服务还优选地包括用于管理边缘服务与客户自己的身份访问管理和持久性解决方案的集成的服务。

此外，边缘管理服务结合了将在云或其他地方开发的、希望部署到边缘的机器学习模型转边为适合在边缘计算平台上实时对连续流式数据执行的优化的经边缘转换的模型的能力。这种转变使原本需要大量计算和存储资产的模型能够在计算和存储资源受限的边缘计算环境中高效执行。这使得强大的机器学习能力不仅可以嵌入到独立的边缘计算平台中，还可以嵌入到大量其他占用空间小、计算和存储资源受限的边缘设备中。

通过将边缘平台及其提供的各种服务保持在相对靠近边缘传感器和其他生成数据的设备，可以在本地实时有效地处理和分析数据，而不是将其发送到远处集中式云。这最大限度地减少了延迟，并允许实现最高性能、更快的响应时间以及更有效的维护和操作策略。它还显著降低了总体带宽要求和管理广泛分布的网络的成本。

作为示例，在根据本发明的示例智能边缘平台上执行的应用可以本地地并实时地监视和分析来自工业IIoT环境中的泵的传感器数据。在一个示例中，基于对数据的实时分析，其中可能包括使用机器学习模型，应用可以实时地输出对泵的预测性维护计划，或者可以在本地网络中自动采取动作以重新引导泵周围的流，以防止因气蚀或其他检测到或预测的事件而造成代价高昂的损坏。在另一个示例中，应用可以监控风能管理系统并且可以输出建议或自动采取动作来改变操作参数以最大化发电、延长设备寿命并应用历史分析以进行准确的能量预测。

除了上述接近性和延迟问题外，上述日常运营的物理设置以及其他工厂、仓库、零售店和其他设施在传感器硬件、网络拓扑、数据协议和数据格式方面也极其异构。这种异构性会导致高昂的软件开发、测试和部署成本。例如，在许多情况下，可能需要开发类似但独立的代码模块来为硬件-网络-数据协议-数据格式的每个组合执行重复的功能。本系统和方法通过在传感器和在边缘计算平台上执行的应用之间采用数字抽象(abstraction)层来避免这些问题。

图5示出了示例边缘计算平台的更详细框图。该平台包括三个逻辑层或部分：数据摄取512、数据处理515和数据发布518。这些层用作传感器和托管在边缘平台上的应用之间的数字接口，以抽象传感器网络中的异构性。在示例边缘计算平台的此表示中，未示出单独的数据富集层。然而，如上所述的数据富集功能的方面在如下所述的数据摄取和数据处理逻辑层中实现。

数据摄取层512的组件包括连接到传感器或设备523的协议代理或居间者520，这些传感器或设备生成数据，例如IoT环境中本地网络或互连本地网络或这些的组合中的传感器和设备。数据摄取层使用多个轻量级、高可用性代理或居间者来实现，以避免单点故障。代理通过来自各个协议服务器的一个或多个协议通过多个网络连接从传感器收集或摄取数据。代理可以充当协议的客户端或居间者，包括MQTT、OP CUA、Modbus和DDS等。代理还摄取各种协议的音频数据，包括MP3、WAV、WMA和OGG，以及各种协议的视频数据，包括MP4、MPEG、MPEG4和MOV。音频和视频数据的摄取可能来自实时流式媒体源或预先录制的文件。传感器或其他网络设备或这些的组合提供或输出的数据通常是二进制数据流。可以通过推或拉方法将此数据从传感器传输或传递到代理。

推描述了一种通信方式，其中对给定事务的请求由发送者(例如，传感器)发起。拉(或获取)描述了一种通信方式，其中信息传输请求由接收者(例如，代理)发起。另一种可以使用的通信技术是轮询，其中接收者或代理定期查询或检查传感器是否有数据要发送。

MQTT(以前称为MQ遥测传输)是ISO标准的基于发布订阅的“轻量级”消息传递协议，用于在TCP/IP协议之上使用。可以使用的替代协议，包括高级消息队列协议、IETF约束应用协议、XMPP和Web应用消息传递协议(WAMP)、以及上面标识的那些和本领域技术人员已知的其他协议。

OPC统一架构(OPC UA)是由OPC基金会开发的用于互操作性的工业M2M通信协议。它是开放平台通信(OPC)的继任者。

Modbus是一种串行通信协议，最初由Modicon(现为施耐德电气)于1979年发布，用于结合其可编程逻辑控制器(PLC)使用。简单而强大，它已经成为所有意图和目的的标准通信协议。它现在是连接工业电子设备的常用方法。

当传感器523被连接时，在传感器和对应的居间者520之间发生连接的会话。然后各个客户端可以发布和订阅与传感器相关联的主题名称。例如，边缘平台的各种组件和应用可以订阅与一个或多个传感器相关联的主题名称。传感器可以经由数据总线532通过居间者520向边缘平台的组件和应用发布各种主题，这将在下面进一步详细描述。还将理解，各种居间者可以作为相对于其他居间者的客户端，因此可以在居间者之间发布和订阅主题。

居间者520优选地是多协议居间者并且被优化以读取和摄取大量数据。在内部，居间者是高性能的，并且使用零拷贝缓冲来进行非常快速的处理。居间者优选具有内置的安全性，以使用安全凭证保护和限制对边缘平台的访问。居间者可以访问包含授权用户登录名和密码对的配置文件，以确定访问是否被授权。此外，居间者优选地具有内置策略以限制授权用户可以访问的主题。这些访问控制适用于内置和种子协议居间者，例如MQTT、CoAP、AMQP或DNP3，也适用于自定义协议。协议居间者的插件架构使得为自定义协议开发居间者变得非常容易。

下面进一步描述的数据处理层515被实现为基于动态计算领域特定语言(DSL)的有向无环图(DAG)模型。这使得边缘平台上对流式数据的处理快速、灵活和直观。然而，由于传感器数据消息可能不会按时间戳顺序到达摄取层512，因此在这样的模型中可能难以知道何时关闭对于针对数据流要进行的任何特定计算的时间窗。居间者520解决了这个问题并且通过跟踪订阅被摄取的数据的每个应用的应用时钟的低水印来支持DAG模型。

数据摄取层512还包括边缘混合器。每个传感器都发布自己的主题。发布传感器测量的时间间隔取决于每个传感器。混合或组合不同传感器发布的测量需要规范化。传感器测量发布到基于时间的通道。测量以循环方式发布到队列中。不同传感器发布的部分或所有测量可以在时间维度上拼接。传感器混合器执行以下传感器时间序列规范化中的一种或多种：规范化到区间；规范化到总和1；规范化到欧几里得范数1；规范化到零均值；规范化到零均值和单位标准差。边缘应用可以通过传感器表达语言(例如FogHorn的)的表达来定义边缘混合器中的流水线工作流。

在进一步描述数据处理层515之前，有必要讨论层之间的数据通信。在此描述的系统和方法采用排队系统来解决在层之间通信数据中的延迟和吞吐量问题。正如利特尔定律所定义的那样，不同级别或层之间的延迟和吞吐量之间的关系非常复杂。每一层都可以被视为一个单独的系统，该单独的系统包括多个子系统，并且可以假设它们之间存在复杂的依赖关系。每个子系统将通过吞吐量或延迟绑定到系统的其余部分。在设计系统时，考虑这些相互作用然后创建一个不会成为更大系统瓶颈的系统是很有用的。例如，如果传感器以高于(其中一个)接收器可以处理消息的速率发送消息，则在层之间的异步通信中会出现流控制问题。

为了解决本系统中可能出现的潜在背压问题(这需要层之间大量数据的异步通信)，创建了一个强大的反应式流处理和排队机制。反应式流处理方法背后的主要驱动力是在存储器中跨异步边界无损传输数据，而无需无界缓冲区。因此使用了延续传递风格(例如，参与者模型)。在这种方法中，当来自下游源的需求达到零时，流参与者将不会从其自己的上游源中拉取更多，并且由于参与者是消息驱动的，因此在下游源有更多需求到达之前，它不会被调度。没有线程为此被阻塞，也没有保留调用堆栈，但参与者记得它在流中的位置。这种设计促进了一种关于级别或层之间消息处理中的非确定性的新思维方式。

现在参考数据处理层515，数据处理层是用有向无环图(DAG)或“流处理图”模型实现的。DAG模型描述了与在摄取层接收的多个传感器数据流相关联的处理单元之间的生产者-消费者关系。图中有源节点、汇聚节点和处理节点，其中有向边代表各个节点之间的信息流。源节点对应于输入数据流的源。这些节点只有出边，它们之间没有任何边。汇聚节点对应于最终处理信息的接收者。这些节点只有通向它们的边，它们之间没有任何边。处理节点代表处理单元。处理单元可能同时需要来自多个数据流的输入，并可能产生一个或多个有价值的输出流。这样的图可以以所有有向边都指向下方的方式绘制。该系统被设计为信息来自顶部并通过中间的处理单元并最终通向底部的输出流。

数据处理515组件包括数据总线532，其连接到数据摄取层512的代理/居间者520。数据总线是所有连接组件之间的数据和控制消息的中心骨干。数据处理层的各种其他组件订阅流经数据总线的数据和控制消息。分析引擎535就是这样一个重要的组件。分析引擎通过执行分析表达域特定语言(DSL)538(例如FogHorn的)的分析表达或从DSL开发的分析表达来执行对传感器数据的分析。连接到数据总线的其他组件包括上述各种边缘软件堆栈服务，包括配置服务541、度量服务544、边缘管理器547和软件开发工具包(SDK)564。

数据总线532包括“解码器服务”，它通过将原始二进制数据解码为可使用的数据格式(例如JSON)以及使用额外的必要和有用的元数据来修饰数据等，来对来自传感器和其他设备的传入数据进行富集。此外，富集可以包括但不限于数据解码、元数据修饰、数据规范化等。

JSON(有时称为JavaScript对象表示法)是一种开放标准格式，它使用人类可读的文本来传输由属性值对组成的数据对象。JSON是用于异步浏览器或服务器通信(AJAJ)或这两者的通用数据格式。JSON的合适替代方案是由AJAX使用的XML。也可以使用其他合适的替代物。

边缘管理器547经由如上所述的任何合适的连接机制连接到云412并且特别地连接到云管理器552。云管理器连接到用于客户身份和访问管理(IAM)555控制的代理，并连接到也在云中的用户界面控制台558。身份和访问管理是安全和业务规范，它使对各种云资源的访问能够在授权时间限于授权个人并出于授权原因。所有前述组件都是上文一般描述的远程边缘供应或编排元素的一部分。云资产还可以包括边缘平台可经由云访问的应用561。

连接到总线的软件开发工具包(SDK)564组件促进了可以在边缘网关平台上部署、驻留和执行的应用567的创建。软件开发工具包还连接到本地时间序列数据库576组件，因此可以访问本地存储在边缘平台或边缘网关上的时间序列传感器数据，以促进开发旨在驻留并运行在边缘平台上的应用。类似地，使用软件开发工具包564开发的应用可以访问时间序列数据库576中的数据。作为一个示例，软件开发工具包可以访问本地存储在时间序列数据库中的聚合时间序列传感器数据以促进开发和训练边缘平台上的机器学习模型，无需传输到远程云设施。当边缘平台上有足够的可用计算能力并且模型可以在不需要非常大的数据集的情况下进行充分的训练或调整时，可能就是这种情况。

使用软件开发工具包开发的应用可以被容器化，从而移动化，以便它们不仅可以在开发它们的边缘平台上而且可以在其他边缘平台实现上以及在云中部署和执行。容器技术虚拟化由操作系统(OS)管理的计算机服务器资源，如内存、CPU和存储装置，开销可忽略不计，并且不需要为每个租户复制整个OS内核。因此，它不同于管理程序技术。容器是作为流行的Linux开源操作系统的一部分开发的，并且随着诸如Docker和CoreOS等高级容器创建和管理技术的可用性，在软件开发和数据中心运营(“DevOps”)方面获得了极大的吸引力。Docker容器将软件封装在完整的文件系统中，该系统包含软件运行所需的一切：代码、运行时、系统工具和系统库——任何可以安装在服务器上的东西。这确保软件始终以相同的方式运行，而不管其运行环境如何。因此，通过在SDK中加入容器技术(例如Docker)，使用SDK开发的应用不仅可以在为其开发的边缘平台上部署和执行，还可以在其他边缘平台实现上以及云中部署和执行。类似地，在边缘上开发的应用可以在云中运行，反之亦然，对于基本上包括机器学习应用的所有应用以及还对于从表达语言(如FogHorn的)派生的表达、运算和函数都是如此。

在示例实施例中，基于诸如所涉及的边缘环境和设备的类型之类的因素智能地创建、部署和管理用于应用的容器。这种智能可以以软件装置的形式实现，该软件装置包括多个组件，包括集中管理、部署拓扑模板、容器移动性管理、零接触边缘部署、容器监控和响应迁移。

集中管理组件包括集中式应用或应用商店，例如用于IoT^TM的IndustrialAppStore。用于IoT的AppStore是FogHorn Systems,Inc.的商标。所有应用部署决策都在应用商店中集中控制和管理，下面将进一步描述其示例实施例。

部署拓扑模板组件包括每个软件应用模块的模板，该模板自包含所有必要的拓扑细节和执行库，用于部署在目的地边缘基础设施上。这包括将所需的网络协议、消息协议和数据格式解析器库组合到服务链中，应用可以使用该服务链访问来自边缘平台所连接的传感器网络中的系统的数据。使用目的地边缘基础设施中的系统配置知识，以智能和自动化的方式执行服务组合。

容器移动性管理组件将包含配置的应用的部署模板对象序列化，并通过互联网或其他网络连接将它们流送到目的地边缘基础设施处的软件装置中的代理。

零接触边缘部署组件包括边缘计算平台处的软件装置，其能够解释从应用商店接收的所配置的容器对象，并将其与在平台中实现的其他分析和数据管理服务一起部署。虽然配置中可能需要一些手动操作，但部署过程是完全自动化的，无需人工干预。

容器监控组件在边缘处的软件平台(装置)中部署基于微服务的架构，其在每个容器中实现遥测代理。该代理测量并报告容器中应用的性能和可用性的详细指标。该平台还能够在这些指标中的任何一个出现异常时发出警报。

响应迁移组件包括触发容器从边缘平台迁移回云的方法，以响应遥测代理观察到的资源争用、服务降级或其他异常或这些的组合。响应迁移组件释放受限边缘基础设施中的资源，并可以提高托管在边缘上的应用的整体服务质量。应用的优先级还可以提供调度此类迁移的标准。

除了时间序列数据库576之外，数据发布518层还包括数据发布器570组件。数据发布器组件通过如上所述的任何合适的连接机制连接到云中的远程存储位置573，并且连接到本地时间序列数据库576。数据发布器组件也连接到数据总线并订阅总线上的数据，该数据将被存储在本地时间序列数据库或远程云存储库中。数据发布器可以将原始传感器数据以及摄取和富集的预处理传感器数据和智能信息传输到本地时间序列数据库576和远程云存储库573。此外，数据发布器可以用于检索存储在本地时间序列数据库中的聚合数据并将数据传输到远程云存储库，例如促进开发机器学习模型以部署到边缘，以及评估和更新已经部署在边缘平台上的机器学习模型。

时间序列数据库(TSDB)是一个软件系统，它被优化用于处理时间序列数据，这些数据包括按时间索引的数字数组(例如，日期时间或日期时间范围)。时间序列数据库通常包括滚动或循环缓冲区或队列，其中随着新信息添加到数据库中，最旧的信息被删除。这种布置有利于在边缘平台环境中使用，因为它有效地利用了在此类环境中通常可用的有限存储容量。

图6示出了示例边缘基础设施602和示例云基础设施(例如图4和5的云412)之间的示例操作流。示例边缘基础设施和示例云基础设施的一些具体方面已经在上面描述以供参考。

在边缘处从传感器606或其他设备或这些的组合收集数据。传感器和设备可以分布在IoT环境中的一个或多个本地网络中，边缘基础设施可以连接到传感器和云之间的网络。例如，传感器可以分布在一个或多个与工业、零售、医疗保健、医疗设备、电力或通信应用或这些或其他的任何组合相关的本地网络中。

边缘基础设施602在物理上和逻辑上驻留在传感器和云或其他远程网络或设施之间。边缘基础设施包括某些硬件组件，例如网络连接和处理器，以及软件边缘平台609，其包括上文关于图4和图5描述的各种组件和元素。因此，在该示例中，软件边缘平台包括数据处理组件612、本地时间序列数据库615、云接收器(cloud sink)618、分析复杂事件处理引擎(CEP)621、分析实时流域特定语言(DSL)624(例如，Foghorn的语言)、以及实时聚合和访问627组件。该平台还可以包括虚拟传感器630，其在下面更详细地描述。可以采用虚拟传感器来提供对富集的实时数据和由此导出的智能信息的访问。

边缘平台的特征和功能可通过一个或多个应用633(例如应用或“app”1、2和3)访问。如前所述，可以使用软件开发工具包或SDK 564开发app。使用SDK开发的应用可以是异构的(例如，以多种不同的语言开发)，但仍然可以部署在边缘上或云中，从而提供边缘和云之间的动态应用移动性。换句话说，app可以用作边缘的一部分，云的一部分，或这两者。由于app被容器化，如上所述，动态app移动性特征成为可能，因此它们可以独立于执行它们的特定计算平台而运行。相同的动态移动性特征还可以应用于集成到DSL 624(例如FogHorn的)或从中导出或这两者的分析表达和函数，也可以应用于机器学习模型，以便它们也可以驻留和执行在边缘平台或云上。

应用利用复杂事件处理引擎621。例如，应用可以触发或调用CEP引擎来对传感器数据执行一个或多个指定分析表达或函数，并生成输出，应用然后可以使用此输出。类似地，可以通过响应于检测到传感器数据中的模式而生成的CEP引擎的输出来触发应用执行某些操作。

可以开发的不同应用的数量与可以设想的潜在技术和工业应用一样广泛和多样。例如，可以开发多种数据分析和应用639以执行多种功能，包括机器学习、远程监控、预测性维护、操作智能以及这些和许多其他功能的组合。此外，许多类型的行政和管理类型的应用都是可能的。例如，允许个体或分布式边缘平台的集成式行政和管理640以及监控和存储在云中或私有数据中心644处的边缘数据的应用可以被开发并部署到边缘平台。

可以使用如上所述的app商店637来分发和部署应用。通过app商店，用户、开发者和其他人可以上传、下载和与他人共享app。例如，app商店可以由边缘平台开发商、客户或合作伙伴提供。app商店还可以作为应用的商业市场。app商店可以作为软件平台来实现，并且优选解决IoT环境和用例中提出的独特的可靠性、安全性、部署和数据管理需求。例如，app商店可以由边缘开发者托管在云中，由独立开发者托管在其他云或远程网络位置，或者由边缘开发者的客户或合作伙伴托管在连接的本地网络或其他网络或这些的组合中。

app商店优选地包括与商店中的每个应用相关联的应用清单。期望提供与每个应用相关联的应用清单，因为IoT环境和应用(尤其是工业IoT环境和应用)具有深入且多样的部署上下文。部署上下文信息可以作为元数据捕获并与应用一起存储。上下文信息可以包括诸如边缘硬件规范、部署位置、关于兼容系统的信息、数据访问控制信息(例如，用于安全和隐私的密码控制)、用于对给定部署中不可用的数据字段建模的模拟器以及版本管理等信息。例如，如前所述，边缘基础设施包括某些硬件作为物理传感器和一个或多个外部通信通道之间的物理层。边缘计算平台还可用于定义虚拟或软件可编程传感器，如下所述。边缘计算平台可以以软件、硬件、固件、嵌入式硬件、独立硬件、专用硬件或这些的任何组合来实现。与给定应用相关联的清单优选地将提供与这些以及可能其他实现特性、特征和要求(应用被设计为关于其发挥作用或应用需要其发挥作用)相关的识别信息和规范。

基于来自边缘平台的部署或下载应用的请求，app商店被配置为基于上面列出的参数将正确的清单与边缘平台的部署场景相匹配。app商店平台还优选地执行特定于边缘部署场景的操作任务，包括数据一致性、应用状态切换和安全凭证管理。这些是应用作为应用容器对象从云或数据中心位置移动到边缘的迁移过程的重要阶段。

如上所述，许多不同的边缘应用是可能的，包括提供一个或多个边缘平台的集成式行政和管理640的app，其可以包括在云中或在私有数据中心644处监控或存储数据。此外，边缘基础设施的应用可以为一些最艰难和最偏远的工业环境提供实时反馈和自动化系统控制等重要功能。FogHorn的美国专利第10,007,513号在第13栏55行到第15栏13行描述了许多特定应用。

仍然参考图6，传感器606包括多个物理传感器，例如分布在IoT环境的本地网络中。每个传感器包括电子换能器，它测量或捕获其环境的一些特性作为模拟或数字测量或值。模拟测量通常使用模数转换器(ADC)转换为数字量。传感器数据可以根据需要进行测量(轮询)，或者可以以统一速率或异步方式作为连续数据流提供。典型的传感器规范是范围、准确度、分辨率、漂移、稳定性和其他属性。大多数测量系统和应用直接利用或传递传感器数据以进行处理、运输或存储。

示例边缘软件平台609的虚拟传感器630也被称为“可编程软件定义传感器”。这些是基于软件的传感器，由分析表达语言(例如FogHorn的分析表达语言)创建。语言被高效地实现，以在执行延迟低的受限低占用环境中支持实时流分析。例如，系统的延迟可以是大约10毫秒或更短。

在示例实现中，可以使用称为“传感器表达语言”或SXL的声明性应用程序接口(API)来创建可编程软件定义的传感器。FogHorn的是SXL语言的特定实现。在此应用中，SXL和可互换使用。通过此构造创建的SXL传感器然后可以从多个来源(包括物理传感器和其他SXL传感器)生成的数据中提供导出的测量。然后，应用可以使用这种导出的智能信息来提供见解、控制动作或用于其他目的。

SXL(例如，)传感器可以从以下三个源中的任一个或这些的组合导出：单个物理传感器、多个物理传感器、以及虚拟和物理传感器的组合。例如，虚拟或SXL传感器可以通过使用动态校准、信号处理、数学表达、数据压缩或数据分析或这些的任何组合通过执行适当的相应分析表达或函数或这两者对传入的物理传感器数据进行转换而从单个物理传感器导出。作为另一个示例，虚拟或SXL传感器可以作为对来自多个异构物理传感器的传入物理传感器数据的组合或转换(使用上述方法)或进行这两者而导出。作为又一示例，虚拟或SXL传感器可通过对来自一个或多个物理传感器的物理传感器数据和来自一个或多个其他虚拟或SXL传感器的虚拟传感器数据进行组合或变换或进行这两者来导出。

SXL(例如，)传感器通常将是特定于领域的，并且将在创建时考虑到特定的应用。SXL编程接口的特定实现使边缘应用能够通过各种转换(例如数学表达)和输入数据的聚合来定义数据分析。例如，FogHorn的在其编程语言中包含一组可用于这些目的的数学运算符。运算符也受Java支持，并且编程接口与典型的物理传感器及其协议很好地集成在一起。

虚拟传感器通常在运行时通过对输入数据执行SXL构造、表达或程序来运行。在示例智能边缘平台中，输入到虚拟传感器的数据通常包括由物理传感器或其他设备生成的流数据，并且虚拟传感器将实时地对数据进行操作并基本上实时地产生分析输出。然而，虚拟传感器还可以对其他虚拟传感器的输出以及先前聚合和存储在例如时间序列数据库中的输入数据进行操作。后者可用于在边缘计算平台上创建和训练机器学习模型，而无需传输到远程网络。同样重要的是要注意，虚拟SXL传感器生成的数据可以存储在边缘平台上的时间序列数据库中，或者可以发送到本地企业网络中的本地存储装置。该数据还可以被传送到边缘或其他应用或在边缘或其他应用内，或者可以传输到其他远程服务(例如，云)，或这些的组合，以进行进一步分析。因此，虚拟传感器既可以将数据作为本地流输出，也可以将输出数据作为第一类数据流发布到边缘平台的数据总线上。

SXL传感器被设计为软件装置，用于对输入数据进行操作并以合适的速率实时地生成分析输出，以供边缘应用使用。为了实现合适的实时执行速率，包括传感器的SXL表达应该在高效执行引擎(例如CEP)中执行，优选在本地计算硬件(例如嵌入式计算硬件)中执行。

可以理解，提供和使用虚拟SXL传感器作为示例智能边缘平台的一部分带来了许多好处。它们是可编程的，因此能够灵活地合成数据，以满足与数据质量、频率和信息相关的特定应用要求。它们还可以作为“无线(over-the-air)”软件而升级方便和广泛地分发，以插入来自物理传感器和其他(例如，预先存在的)SXL传感器的数据。这允许应用开发者创建数字基础设施，有利于独立于物理基础设施布局的业务逻辑的高效执行。它们可用于在应用和物理传感器之间创建数字抽象层，从而使开发者免受物理传感器升级和服务导致的物理基础设施变化的影响。它们还可以通过将来自物理传感器的大量原始数据转换为更有限信息的精确表示，例如有用或感兴趣的分析见解，从而提高信息管理效率。这种效率转化为更有效地对可能在边缘处受到严重限制的IT资源(例如计算、网络和存储资源)的利用。此外，由于它们生成从现实世界或物理传感器数据流计算出的实时数据和信息，因此它们可以以最小的时间延迟(即基本上实时地)使数据可供边缘应用使用。

用于使用声明性SXL(通常为API，更具体地为FogHorn的语言)从泵的物理传感器生成的流、压力和温度数据中导出压差和蒸汽压力数据的虚拟传感器的示例关于FogHorn的美国专利第10,007,513号的表A和B分别具体显示和描述。此外，示例演示了如何使用虚拟传感器得出的分析信息来生成泵气蚀警报。这些示例及其相应的解释通过引用并入本文。

图7示出了用于从输入创建虚拟传感器的传感器表达语言引擎707。传感器表达语言引擎从物理传感器或其他虚拟传感器获取输入。输入的一些示例包括入口压力711、出口压力714、温度717和流720。任何数量的输入或输入的组合可以用作虚拟传感器的输入。基于输入，传感器表达语言引擎可以生成具有一个或多个输出的一个或多个虚拟传感器，输出例如压差731、温度734(其可以是开尔文为单位)和蒸气压737。应当理解，虽然图7示出了多个框(例如，731、734和737)，每个框代表具有单个输出的虚拟传感器，但虚拟传感器可以具有多个输出。例如，虚拟传感器731和734可以组合成具有两个输出的单个虚拟传感器，或者虚拟传感器731、734和737可以组合成具有三个输出的单个虚拟传感器。实际上，可以定义任意数量的虚拟传感器，并且可以将每个虚拟传感器定义为具有任意数量的输入和输出。如上所述，虚拟传感器的每个输出可以是虚拟传感器的一个或多个输入的数学函数、输入的聚合或其他组合、输入的逻辑函数、这些的组合等等。

一般而言，在如上所述的示例智能边缘计算平台的示例操作方法中，应用开发者向边缘平台表达由他们的应用软件使用的数据语义并向其暴露他们的应用存储库。根据希望执行的操作和希望在边缘完成的功能，将一个或多个应用部署到边缘平台。一个或多个部署的应用在边缘平台上执行，并且可以访问由连接的本地网络或多个网络中的一个或多个物理传感器生成的一个或多个摄取和富集的数据流以及来自在边缘平台上执行的一个或多个虚拟传感器的一个或多个虚拟传感器数据流。应用实时地对数据流进行操作，这可以包括在其上执行分析表达和函数，并识别数据中表示与本地网络中的操作、设备、机器等相关的事件、发生、状况等的模式和语义。应用还可以实时地分析数据流，这可以包括在其上执行分析表达和函数，并且可以生成智能信息或其他分析信息、或这些的组合或结果。

应用可以做出决定，并且可以使传感器数据流或其部分本地存储在边缘，传输到远程云进行存储或处理或进行这两者，或分析，或这些的任何组合。应用可以做出决定并使智能信息或其他分析信息或这些的组合被本地存储或传输到远程云。应用可以基于传感器数据、智能信息或其他分析数据或这些的组合触发要在连接的本地网络中采取的动作。

应当理解，基于在传感器数据中发现的各种语义，边缘应用可以智能地定制要执行的服务和分析的组合，这可以包括出于各种目的而与其他应用(包括本地企业网络中边缘上、云中或其他计算平台上或这些的任何组合的其他应用)的执行进行通信或调用其他应用的执行或进行这两者。协作应用可以在云和边缘平台两者处执行，并且可以使用边缘平台上的软件服务来管理应用间的通信。

从软件的角度来看，本地网络中生成的传感器流数据可能会触发托管在边缘网关平台或设备或嵌入式系统上的软件层。软件层连接到局域网传感器网络。软件层在边缘计算平台上或云中提供服务、应用和数据处理引擎的存储库或这些的组合。软件层对传感器流数据执行分析表达，并通过软件层提供的表达语言将传感器数据与特定状况发生的语义描述相匹配。软件层通过不断执行表达，自动实时地发现流数据中的模式事件。基于匹配的语义，软件层可以智能地跨边缘网关设备和由软件层管理的网络上的嵌入式系统组合服务和应用，以链接应用和要执行的分析表达。可以基于资源可用性来组织应用和分析的布局。可以远程监控软件层的健康状况。软件层或由此调用的应用或服务可能导致原始传感器数据或由对数据执行分析表达产生的富集数据或智能信息存储在本地时间序列数据库中或远程存储在云存储库中。可以将服务、应用、表达、函数和其他软件组件容器化，以确保在任何网关环境中顺利运行。

在另一个示例性的一般方法中，对服务的调用由在边缘网关平台或设备或者连接到广域网的嵌入式系统或设备上托管的软件装置中接收的传感器数据触发，其中软件装置可以访问服务、应用和数据处理引擎的存储库。软件装置通过对数据执行表达语言的分析表达，将传感器数据与软件装置提供的数据的语义描述相匹配。在确定匹配后，软件装置发现为匹配的数据的语义类型的模式设计的所有应用，智能地跨边缘网关设备和分布在由软件装置管理的广域网中的服务器组合服务以链接匹配的所有应用和分析，并基于边缘网关设备处的资源可用性优化应用和分析的布局。

软件装置通过利用来自传感器数据和存储库中的应用的动态上下文来智能地组合服务链的示例方法解决了与传感器、数据、协议、网络环境和计算环境的不同异构性相关的许多问题；由于需要处理和分析的大量传感器数据以及基于云的服务的远程性，导致所谓的最后一英里差距；IoT软件的安全性和数据孤岛挑战必须针对众多不同的平台、传感器、设备、网络和计算环境进行重新设计、重新配置和重新部署。

更详细地说，一个或多个传感器数据流通过边缘网关平台或设备的多个网络接口到达软件装置。软件装置检查每个数据流中的消息报头以寻找指示所支持的已知数据协议的模式。在发现所支持的协议的模式后，软件装置在组合的第一阶段加载相关协议居间者服务并摄取数据流。

软件装置通过协议居间者发现数据流中数据语义的维度，匹配应用开发者表达的语义中的模式，并创建匹配元素的评分列表。所有匹配扫描都由令牌交换协议保护，以确保开发者可以访问匹配的数据。该装置可以加载匹配分数最高的数据语义，或者通过人机界面进行推荐用于人工确认。服务组合添加了开发者数据语义。

然后，软件装置根据需要混合来自不同物理源的传感器流数据，以匹配所发现的应用的数据语义定义。

所发现的应用的分析服务依赖性由传感器附近的边缘网关平台或设备上的软件装置以及同一装置管理下的数据中心中的其他服务器进行分析和提供。

具有适当语义的数据流由软件装置通过数据处理流水线传送，以根据所发现的应用的需要转换数据。

软件装置通过安全链接管理跨广域网的数据传输，以确保地理上分布的分析处理流水线之间的一致性。

所发现的应用可以通过之前向开发者(例如在软件装置的手册中)公开的编程API(具有基于令牌交换的安全性)安全地访问转换后的数据。基于该实例所需的服务质量和资源的可用性，将所发现的应用链接到适当场所(边缘网关平台或设备、数据中心服务器)的服务组合。

边缘计算平台上的机器学习能力

现在，描述将更具体地转向示例软件边缘平台的机器学习方面。在可以为示例边缘计算平台开发、部署和执行的众多应用中，采用机器学习的应用特别强大。机器学习已发展成为自动发现数据中的模式并使用构建的模型在各种垂直行业中产生智能预测或推理的关键计算结构。机器学习对传感器数据的应用与整个物联网(IoT)细分市场中数据驱动的业务和运营规划用例相关。

然而，在边缘处将机器学习应用于传感器数据带来了各种可扩展性和效率挑战等。部署在物理操作中的控制系统和机器通常会生成非常大量的连续流数据。然而，典型的机器学习(ML)模型是为用于批量或微批量静态数据而开发的，并且不适用于来自传感器的高速、大容量流数据以及要在边缘计算平台处本地处理和分析的其他数据。此外，成本和物流限制了在边缘处聚合此类数据以进行机器学习分析的能力。

在工业系统操作中生成的传感器和其他数据通常具有非常少的结构和与之相关的元数据，并且数据损坏和缺失值非常普遍。此外，构成所生成的数据的特征在类似操作系统的不同实例之间差异很大。这严重降低了通过传统机器学习分析所开发的ML模型能够从此类数据产生的结果的保真度。

与此相关的是，ML模型通常开发为必要的、昂贵的和需要资源的预处理(数据对齐、调节、过滤等)和后处理(聚合、警报生成等)逻辑合并为模型本身的组成部分。此外，典型的ML模型是在假设基本上无限的计算能力可用的情况下开发的，因此通常很少或没有对模型大小和权重的限制。然而，如本文所述，边缘计算平台通常是资源受限的，尤其是在计算能力、本地存储和其他方面，这使得在边缘处成功合并典型的ML模型变得困难或不可能。

通常情况下，正确高效地执行对输入数据的预处理实际上是ML模型预测正确性的核心。如果训练中使用的数据与生产中使用的数据不紧密一致，那么ML模型真的很脆弱——因此，预处理步骤的重要性使得ML模型在实际业务环境领域中有用。

在大多数实际场景中，大约50％的ML模型代码用于数据预处理功能。通常在云中，这是通过宏批处理风格的复杂数据处理流水线完成的，其中每个阶段的输出有时会进入内存存储库或数据库或文件系统，然后由下一阶段获取。这在存储装置和磁盘方面给运行时基础设空间占用带来了沉重的处理负担。尽管在具有大量可用计算和存储资产的云环境中，这种负担可能不是问题，但边缘(存储装置和CPU)的限制不允许像基础设施运行时这样的云来支持ML模型评分/推理/执行。

如上所述，除了边缘上的基础设施运行时限制外，在边缘处应用ML模型(尤其是用于工业和商业IoT解决方案)的其他最大挑战之一是在流式背景下处理ML推理(预测)相比针对所记录的历史数据执行模型之间的内在语义差异。在为IoT网络的边缘处的电梯运行预测性维护分析的背景下，可以说明这方面的具体示例。在这种情况下，边缘平台上的存储器和存储装置资产受到限制，传感器以大约5毫秒的间隔连续将数据流送到边缘平台。通常在云环境中，会开发并执行一种算法，该算法会在几分钟内收集传感器数据，并对收集的静态数据运行数字运算和ML推理。然而，在这种方法中，电梯的实时状态将是实时未知的。换句话说，基于云的ML模型提供的所有推理和见解都是事后或后见之明的。此外，如下面关于图11所示和描述的，在将数据从边缘上传到云的过程中可能会丢失对产生准确预测至关重要的数据值。

此外，由于存储器和存储装置限制，这样的ML模型甚至无法在边缘上运行。相比之下，本文所述的“边缘化”ML模型能够在具有受限资源的边缘上实时地在指示当前电梯状况的流送传感器数据上运行，能够基本上实时地预测即将发生的故障，因此能够立即触发警告或补救措施。

虽然在云中比在边缘处实现更高的预测保真度(ML推理)是可能的，但增加的保真度是在聚合水平上实现的。相比之下，边缘处所需的预测(ML推理)通常处于更精细的级别。根据上面的示例，期望基于传感器生成的所有数据值来预测电梯状态并在刚发生时检查，而不是检查过去的情况。因此，迭代的云-边缘闭环机器学习中的最大差距之一是转换ML模型以在实时流数据环境中执行，同时仍保留在云环境中执行所需的ML模型的确切语义。

在此描述的具有机器学习能力的示例边缘平台和相关方法克服了与典型的基于云的机器学习模型相关的前述缺陷。它们实现经过转换并优化以在边缘处实时高效地对流送传感器数据执行的机器学习模型，并提供在IoT尤其是IIoT环境中非常有用的即时并准确的预测和见解。基于边缘的机器学习模型无缝连接到边缘平台处接收的流送传感器数据。通过在模型被应用于数据之前在复杂事件处理器(CEP)中执行源自FogHorn的表达语言的选定表达，可以实时地完成对原始传感器数据的预处理和富集(清理、过滤、规范化和上下文化)。在程序控制下对传感器数据进行预处理使其能够以为每个模型指定的形式直接呈现给各种模型。模型输出的后处理同样通过在CEP中执行适当的表达来完成。由于这些模型减轻了与预处理和后处理相关联的大量处理负担，因此它们能够在边缘计算能力有限的情况下快速、高效地执行。

此外，模型本身经过转换并优化，以在边缘平台上实时高效快速地对流送传感器数据执行。这可能包括优化模型计算，并将模型从典型的基于云的高级机器学习模型语言(例如Python)或规范(例如PMML、PFA、ONNX等)完全或部分转换为分析表达式语言(例如)的表达脚本，其专门适用于在CEP中高效执行。因此，经转换并优化的模型能够对在边缘平台处接收到的流送传感器数据非常快速地实时执行，并以足以让基于边缘的机器学习应用触发即时动作的速率提供即时输出。模型创建和训练仍然可以在云中完成，那里有大量的计算和存储资源可用。一旦模型被训练，它就可以被“边缘化”，如本文所述，并被推送到边缘以进行实时地执行。最终，边缘处模型产生的推理可以频繁发送到云以进一步调整模型，更新后的模型以高度迭代的闭环方式推回边缘。在这方面，IIoT中的“AI”实际上可以被视为对于云机器学习和模型“边缘化”的闭环边缘。

一般而言，此处描述的示例软件边缘平台被设计为能够执行机器学习工作流，这些工作流跨越传感器网络边缘处可用的本地计算资源和远程数据中心或“云”站点中可用的资源。软件边缘平台处理原始传感器数据的连续流，并在边缘处聚合处理后的数据。该处理由机器学习分析的开发者通过API在程序控制下执行，以对指定用于机器学习分析中的数据进行预处理。机器学习模型是根据机器学习分析构建的，然后可被部署到边缘平台以实时地在传感器数据上执行。

软件边缘平台能够提供对传感器数据(根据上述机器学习工作流构建的机器学习模型可以在该传感器数据上执行)的查询和预处理，并将模型执行的结果发射到云以进行模型评估。软件边缘平台还能够通过基于数据中的组成特征集对原始传感器数据进行分区来在边缘处提供传感器数据分割，并将分区数据与根据上述机器学习工作流构建的相应机器模型进行智能匹配。

软件边缘平台还能够基于上述对传感器数据进行预处理、对经预处理的传感器数据进行基于查询的模型执行、以及基于特征的数据分割和智能匹配的工作流，在边缘处提供实时模型训练和选择。

软件边缘平台的上述能力一起可以作为服务有效地构成机器学习的系统结构。

软件边缘平台还可以协调在边缘平台的实例上以及跨可以分布在广泛地理区域的边缘基础设施的多个实例上的模型执行和通信。模型可以跨不同特征空间的片段对传感器数据执行。通过使用云作为迁移学习的平台，边缘平台可以将学到的知识跨不同的特征空间迁移。通过避免数据标记和利用具有异构标签的数据，这为机器学习过程带来了很多效率。

具有机器学习能力的示例边缘计算平台将用于各种工业和其他应用或用例。在FogHorn的美国专利10,007,513(例如，参见第25栏第60行至第27栏第29行)中识别和描述了许多示例用例，该专利与本申请中引用的所有其他参考文献一起通过引用并入。

图8是总体功能框图，图9是更详细的功能框图，示出了具有机器学习能力的示例智能边缘计算平台406、609和相关方法。如前所述，边缘平台406、609包括数据摄取421、512和富集425组件。这些组件从本地网络中的传感器和设备523接收原始或“脏”数据流，将它们摄取到边缘平台并富集它们以准备由基于边缘的ML模型进行操作。

富集可以包括例如解码或规范化数据或这两者都进行，例如以本文先前确定的方式之一。富集还可以包括识别丢失的数据测量或点并以任意数量的方式替换数据，例如通过从相邻数据点进行插值或求平均值。富集还可以包括识别超出预期范围的数据元素或其他异常值并采取纠正措施。富集可以包括更正或恢复已损坏的数据、或这两者都进行。富集还可以包括添加或“装饰”某些元数据，以及其他清理、过滤或情境化，或这些的任何组合。它还可以包括对从多个源接收的数据进行对齐或聚合，或这两者都进行。对于音频和视频数据，富集还可以包括图像大小调整、颜色转换、上下采样等。从本质上讲，富集可以包括将原始传感器数据转换为更准确且可由机器学习模型使用以产生准确推理的形式所需的任何内容。

应该理解，虽然对所接收的数据的富集可以被认为是模型操作之前的一种数据预处理类型，但它在重要方面与基于云的ML模型中通常包含并在下面进一步结合此类模型的边缘转换描述的预处理类型不同。在这种情况下，预处理涉及对可能多个已经富集的数据流的操作和处理，以生成特定模型指定的特定数据输入流。这种预处理可以包括对来自流的数据进行例如上下文化、对齐、运行统计或数学函数或这两者、过滤、平滑、分组或聚合，或这些的任何组合，或以其他方式从流形成模型指定的特定数据输入流。

如上所述，对原始传感器数据流的数据摄取和富集优选地在经由API的程序控制下执行，并且应当理解，可以对经富集的数据流执行预处理并且优选地类似地执行。还将理解，对模型输出的任何后处理(例如警报的聚合或生成)可以并且优选地被类似地处理。

更具体地说，可以在边缘平台上通过在CEP引擎429、535、621中执行表达语言435、538、624(优选FogHorn的)的表达脚本来执行对数据摄取和富集以及任何预处理和后处理。当在平台处接收流时，实时地执行摄取、富集、预处理和后处理。因此，示例边缘平台允许并支持特别适合在边缘处执行的机器学习模型，这些模型不需要并且优选地不合并原本在基于云的模型中通常合的大的、昂贵的和计算资源繁重的预处理和后处理。

如前所述，具有机器学习能力的示例边缘平台包括数据分析435(图4)、538(图5)、624(图6)和CEP引擎429(图4)、535(图5)、621(图6)组件，它们分别合并了使用分析表达语言538(例如FogHorn的)定义的分析表达和函数，并且包括用于执行这样的表达和函数的分析引擎。如前所述，在摄取和富集过程期间检测传感器数据中与某些特性或特征(即语义，例如主题、字段、数据类型和值对等)匹配的模式可以触发CEP对数据执行相应分析表达或函数或这些的组合，以产生各种分析结果。边缘平台上的应用432(图4)、567(图5)、633(图6)和ML模型也可以基于这种检测被触发以由CEP执行，并可以访问CEP对表达和函数的执行的结果。应用和模型还可以根据应用或模型或这些的组合的需要调用CEP 432来执行分析组件435的分析表达。

具有机器学习能力的示例边缘平台还包括机器学习软件平台804。机器学习平台的特定实现是FogHorn的Edge ML^TM。机器学习软件平台804优选地包括可以在边缘平台上选择和执行的多个标准ML模型。它还优选地并入了用于导入额外的自定义或专有模型以及用于导出模型的功能，例如用于在其他边缘安装上的部署。

虽然机器学习平台804被示为边缘平台406、609的一部分，但应当理解，该平台可以驻留在与边缘平台相同的计算平台上或例如在云中或本地企业网络中的另一个计算平台上并在其上执行，并通过互联网或其他本地或远程网络连接与边缘平台进行通信。机器学习软件平台上的模型可以手动地选择以并入到边缘平台上的工作流中，并且可以由在边缘平台上执行的应用调用。

尽管可以将各种标准ML模型并入作为机器学习平台804的一部分，但是应当理解，可以在边缘平台的特定实例上容纳的不同模型的总数可能受到存储约束的限制。还应该理解的是，一些模型可能由于其复杂性、可用的有限边缘计算资源、以及对于模型能够分析连续流数据并基本上实时地基于这些数据产生预测或推理的希望而并不特别适合在边缘处使用。在当前优选的示例实施例中，标准模型至少包括分类模型(决策树分类、逻辑回归分类、高斯和多项式朴素贝叶斯分类、最近邻(KNN)分类、神经网络分类(CNN、RNN)和支持向量机分类)、回归模型(决策树回归、广义线性模型，包括ARIMA、线性、拉索、弹性网络和岭回归)、最近邻(KNN)回归、神经网络回归和SVM回归)、聚类模型(均值-漂移、K-均值)和异常检测模型(孤立森林、一类SVM)。

ML模型开发和边缘转换

向示例边缘计算平台提供机器学习能力的第一步是开发选定的ML模型。下一步是将模型边缘转换或“边缘化”为适合在资源受限的边缘计算平台上执行并实时地在连续流实时数据上操作的形式。最后，将边缘转换的模型部署到边缘平台。

ML模型通常在“开发”计算环境(例如云计算环境412)中创建。模型通常用高级编程语言(例如Python、R、SAS、Knime等)编写。当模型旨在在不同的“生产”计算环境中对“实时”数据执行时，它们可能会被导出或转换为通用或标准形式，例如预测性建模标记语言(PMML)、PFA、ONNX或类似的东西，以适应它们从开发环境到操作环境的部署。

新ML模型的开发和训练通常涉及使用复杂的数据挖掘、模型创建以及模型训练过程和组件。此类过程和组件通常需要并在大量历史或合成静态数据或这些的组合上运行，以创建和训练模型。通常需要大量的存储库和计算资源。因此，可以使用模型创建组件902、模型训练组件904以及数据存储和聚合组件573在云412中适当地开发和训练要部署到示例边缘平台406、609并在其上执行的机器学习模型。模型创建和训练组件902、904可以包括已知的高级编程或模型开发软件或这两者，例如Python^TM(Python软件基金会)、R、RStudio、(The MathWorks,Inc.)、TensorFlow^TM(Google)和Spark^TM MLlib(Apache)。数据存储组件573可以包括已知的大容量数字存储组件，例如磁盘或其他电子存储设备。计算资源可以适当地包括各种已知的处理器。

用于开发和训练模型的聚合或分批数据优选地包括在边缘平台406、609处接收并经处理(包括摄取和富集)的传感器数据。如前所述，机器学习模型开发者可以以编程方式控制边缘平台的分析和CEP组件429、435、535、538通过API执行的摄取和富集功能。因此，他们可以使用边缘平台来生成开发和训练数据集，其中包含针对正在开发的任何特定模型已进行适当富集和格式化的数据。这些数据集在语义上也与实况数据(这些数据在被边缘转换并部署到边缘平台后，模型将在这些数据上执行)基本相同。

如本文所述，为示例边缘平台开发的模型不需要并且优选地不包括实质的预处理代码和功能，这些预处理代码和功能通常并入为在非基于边缘的计算环境中对批处理数据执行而开发的模型中。为示例边缘平台开发的模型所需的任何预处理都可以与模型分开而在边缘平台上执行，方法是在CEP引擎中在程序控制下对摄取和富集的数据流执行分析表达。这种预处理可以包括例如在时间、计算或现实世界事件或这些的组合方面的数据上下文化、数据对齐、运行统计或数学函数或这些的组合组合、过滤、平滑、分组、或聚合或这些的组合，或以其他方式由特定模型指定的一个或多个流特定输入数据流形成。出于相同的原因，为示例边缘平台开发的模型也不需要并且优选地不包括通常包含在设计为对批处理数据执行非基于边缘的模型中的后处理代码和功能。因此，模型开发者可能会专注于开发模型本身，并假设输入和输出将根据边缘处的要求进行预处理和后处理。即使模型是在集成预处理和后处理的情况下开发的，当模型被边缘转换并部署到示例边缘平台时，预处理和后处理组件也可以并且优选被删除并替换为等效的表达的脚本。

参考图5和图9，用于开发和训练模型的数据可以在边缘平台处被聚合，例如存储在本地时间序列数据库576中，然后可以由数据发布器570组件传输到云412。在云中，数据可以存储在云数据存储器573中。存储在云中的开发和训练数据还可以包括来自边缘平台406的其他历史传感器数据、来自连接的本地网络的传感器数据、来自其他网络的传感器数据、或各种合成数据、或这些的组合。各种预测、推理、分析结果和其他智能信息(例如在边缘平台上执行的应用、分析表达和机器学习模型产生的业务和运营见解)也可以通过数据发布器发送到云，用于创建、验证、评估和更新模型，如下所述。企业参考数据802也可以从此类数据的任何可用源访问，例如使用诸如OSISoft之类的应用，并经由数据发布器传输到云。

使用批量静态数据创建和训练各种已知类型的机器学习模型(例如线性回归模型)的各种手段和过程已经存在，已被发布并且是本领域普通技术人员已知的，包括以上被识别的那些。因此，创建和训练此类模型的细节在此不需要进一步描述。

一旦模型被开发和训练，模型必须进行边缘转换或“边缘化”，以使其适合部署到边缘计算平台并在其上执行。边缘转换组件906用于将机器学习模型边缘转换或“边缘化”成一种形式，该形式被优化以在边缘平台406、609上高效且快速地执行，实时地对实时流数据进行操作，并实时地从数据中产生推理。边缘转换组件906可用于转换标准模型和任何定制或专有模型以被并入作为边缘平台的机器学习软件平台804的一部分。

边缘转换组件906可以直接从高级语言(例如Python)的原生形式或者从中间形式(例如PMML、PFA或ONNX，如果模型最初不是以原生形式创建)对模型进行边缘转换。模型通常从创建它们的高级语言转换为中间形式，例如PMML，以适应模型从开发环境到不同操作环境的部署。为了在下面提供转换过程的详细示例，假设模型已转换为PMML。

例如，将使用众所周知的模型开发软件产品或语言之一或它们的组合所开发的模型转换为PMML的过程是众所周知的，并且常规和各种工具和实用程序可用于该目的。但是，仅将模型转换为PMML不足以使其适合部署到示例边缘平台并在其上执行。该模型还必须被优化并转换成能够在边缘平台406、609上高效快速地执行并且能够在平台处接收的实时连续流数据上实时地操作的形式。

作为边缘转换过程的一部分，边缘转换组件906可以将高级模型或中间PMML版本的全部或部分转换为等效的合适的分析表达语言(优选地)的表达的脚本。这降低了模型的大小和复杂性，使其能够在边缘平台的CEP中以有限的边缘计算资源更有效地运行，并使其能够实时地对连续流送传感器数据进行操作。然而，从以下示例转换和优化过程的详细描述中可以理解，模型也可以被优化和转换以在边缘平台上执行，而不必将其转换为或其他类似的分析表达。

因此，边缘转换使以前限于在云中执行的强大机器学习模型和应用能够在示例边缘平台上实时地对连续流送传感器和设备数据执行。将云生成的ML模型从其高级原生格式或中间格式转换为通用分析表达语言(例如)的表达脚本的另一个好处是，它允许同一边缘平台容纳多个异构ML模型。

下面的表1是以PMML表示的简化ML模型的示例，并以典型方式创建以用于非边缘计算环境。该模型在制造环境中使用逻辑回归，基于绕线机温度、线径、绕线机速度和线张力的传感器输入来推理铁芯绕线机即将发生故障的概率。

表1

下面的表2是表1中以PMML表示的ML模型的经转换或变换版本的示例，该模型适用于部署到示例边缘平台406、609并在其上实时地对实时流送传感器数据执行。

表2

将模型的PMML版本(表1)与转换后的版本(表2)总体进行比较，可以理解的是，在PMML版本中，模型输入被定义为静态传感器数据值，而在VEL中版本，它们被转换为对连续传感器数据流的定义。此外，在PMML版本中，静态传感器数据值的离散集以顺序方式作为输入进行操作，以产生一系列离散推理(即，即将发生的绕线机故障的概率)作为所处理的每个离散输入数据集的输出，而在转换后的版本中，连续的输入数据流被实时地操作，并产生连续的推理流作为输出，可以对此输出立即采取动作。

主要参考图9和10，边缘转换组件906接收已经使用复杂数据挖掘、模型创建和模型训练组件902、904创建和训练并且可选地已经转换为标准中间格式(例如PMML)的模型用于部署。边缘转换组件读取并解析高级模型代码或PMML规范，并且可以根据特定实现的需要或期望，将其完全或部分转换为功能和语义等效的分析表达(优选是表达)的脚本。边缘转换组件906还可以从模型中删除任何集成的预处理和后处理功能，并将它们转换为等效的分析表达，这些表达可以与模型函数分开地在CEP引擎中更高效地执行。向分析表达的转换使模型能够在边缘平台的CEP引擎中更高效、更快速地执行，同时保持语义等效性。此外，转换使模型能够实时地在连续的实时传感器数据流(而不是先前已批量处理和存储的静态数据)上执行。

如前所述，某些高级模型语言表达或函数可能适合以其原生形式在边缘平台上执行，而无需转换为等效的分析表达。此外，某些模型可能包含没有等效项的功能。如果特定模型的某些功能在中没有等效项，则该功能的原始高级语言代码或PMML规范可能会保留或转换或进行这二者以成为等效的可执行代码，例如C++，该可执行代码可以通过将适当的表达、构造或活动对象绑定到该代码并调用该代码而在运行时执行。然而，为了最大限度地提高大多数模型在边缘平台上执行的效率和速度并最大限度地减少模型在边缘平台上的资源使用，通常优选尽量减少非代码的部署。

值得注意的是，对于各种基于云的运行时环境和框架，有许多解析器可用于高级模型语言和PMML。然而，由于诸多限制，此类解析器通常不适合在边缘处实现机器学习。例如，此类解析器通常执行线性代数或简单表达评估等计算。它们也不提供用于处理在边缘处实时地处理多个异步传感器数据流所涉及的时间方面的固有机制。以模型期望的正确格式将输入数据提供给模型所需的任何数据预处理完全留给可能希望使用该模型的应用开发者。此外，此类解析器通常并非设计为生成高效且轻量计算需求并且在有限的边缘计算资源下运行良好的代码。更进一步，包括多个链接模型的模型通常在链中被处理时线性地进行通过多个不必要的数据/计算表示，这是低效的。

用于优化来自云或任何其他系统或工具的所训练的ML模型(被表示为PMML)并将其转换到等效的高效表示的示例转换器和方法克服了上述缺陷。该示例转换器和方法有效且精确地将PMML转换为作为输入和反应函数的组合，优化用于在边缘处的高效执行，同时解决了代码还必须能够实时地一起处理传感器或其他设备数据的多个异步流。可以理解，可应用下面描述的相同方法用于优化和转换高级语言而不是像PMML这样的中间形式的模型。

PMML规范通常包括以下组件：

1.输入参数和类型；

2.要执行的任何预处理步骤；

3.要应用的精确ML算法；

4.来自算法的任何元数据或超参数；

5.要执行的任何额外的任意计算；

6.预测输出和类型；

7.要执行的任何后处理步骤；和

8.任何与(一个或多个)附加ML算法的链接(每个算法都有相关联的组件)。

示例转换器和方法将PMML模型文件作为输入，并生成具有等效语义的等效程序作为输出。示例转换器和方法优选地支持在PMML规范中定义的所有功能、类型、算法和转换。示例转换器和方法可以用C++实现。PMML规范中指定的所有ML算法也可以在C++中实现，以便在运行时进行快速计算。

转换器识别PMML输入的模型类型并执行特定于模型的代码生成活动。虽然许多模型可以直接在中表示，但对于某些复杂模型的一些复杂计算，可能没有直接的等效项。对于这些情况，特殊功能内置到中，并在生成的程序内直接被调用。例如，诸如梯度提升树(XGBoost)模型和某些类型的深度神经网络模型的模型非常复杂，具有数千个树节点。支持有状态的活动对象，这些对象提供了在程序启动时直接将这种复杂的PMML模型构建为高效并优化的C++对象的基础结构。一旦有状态对象启动，当用于预测的输入数据到达输入流时，预测将直接在原生C++代码中完成。有状态的参与者对象运行得非常快，从而为边缘处的时间关键应用提供高性能的实时预测。

示例转换器和方法优选地分三个阶段将PMML输入转换为输出。在阶段1，解析XML内容并在内存中构建表示，以捕获语义、关系、转换和ML算法技术以构建计算流图。在阶段2，执行一系列图形和转换分析以优化任何计算、整合任何预处理步骤、可在编译时折叠的折叠操作，并构建从函数和有状态对象的库选择正确的转换和函数工具包的自描述结构。在阶段3，展开在阶段2创建的结构并组装组件以生成完整的代码对象。阶段3可以包括向用户询问要使用的任何开箱即用的输入组装模板。还可以向用户提供要使用的任何后处理模板。然后代码被生成以实现目标平台的最佳程序。由ML模型创建者嵌入PMML文件中的任何测试用例也被生成，作为代码生成程序本身的一部分而生成的静态期望，因此它们可以在模型被部署到示例边缘平台之前在编译时被验证。这大大增加了对代码生成准确性的信心。

在制造用例环境中，结合下表3和表4展示了示例PMML规范到代码转换。在这个示例中，机器生产用于电容器的铝卷(aluminum roll)。电容器的寿命和健康状况与制造的每个铝卷关联的健康状况和制造条件有关。因此，在制造过程发生时实时预测铝卷是好是坏将非常有用。

表3中显示的PMML规范描述了预测性机器学习模型，该模型使用物流回归(Logistics Regression)作为机器学习算法。该模型已在云中进行训练，现在需要将其部署到制造铝卷的工厂的边缘平台处，以在制造过程进行时实时地现场预测卷的健康状况。在这个用例中，没有时间查看事后数据；预测越延迟，产生代价高昂的废品的可能性就越大。

表3

对应于PMML(XML)规范的等效转换的代码如表4所示。

表4

将PMML规范与已变换的经边缘转换的代码进行比较，首先可以看出，在PMML规范中，各种数据输入是静态标识的，并且它们各自的数据类型在<DataDictionary>下声明。在程序的相应部分中，输入数据流使用“def stream”声明进行标识和定义。代码中的数据流定义比PMML规范中的数据输入和类型声明更广泛，部分原因是PMML规范假设输入数据已经被聚合、清理和上下文化，而边缘就绪代码假定输入数据将包含要实时处理的原始传感器数据流。因此，PMML规范本质上更静态，而版本具有更连续的时间性质。

此外，PMML规范假设输入数据已经过预处理，以便各种输入对齐，即，来自一个传感器的数据元素按顺序或时间帧与来自其他传感器的相应数据元素对齐。一般来说，机器学习模型不能在数据输入不能很好对齐的情况下很好地工作或者提供准确的结果。因此，PMML规范仅描述数据输入及其类型，并假设应用开发者将在数据输入到模型之前执行必要的数据预处理。相比之下，经边缘转换的代码假设来自各种传感器的数据元素将异步到达，并且在输入模型之前必须按顺序或时间帧和相关性对齐。因此，变换器和方法首先吸收PMML规范以理解各种数据输入及其类型和交互。然后，转换器和方法按名称、设备类型和数据类型将各种PMML数据输入映射到相应的“现实世界”传感器数据流输入。转换器可以自动向“现实世界”传感器数据流提供智能映射，这些数据流在名称、设备和数据类型上对齐，供用户选择。许多预先打包的模板可以预先开发并可供用户选择所需的精确对齐语义，而无需任何额外的编码或开发工作。

在本示例中，希望每次从用于温度、直径、速度和张量的四个传感器中的每一个接收到新的数据值时生成预测，其中传感器正异步地生成这些数据值，而不是相互时间对齐。在代码中，在如上所述标识和定义各种传感器数据流之后，可以将构成每个流的多个数据值组合成用于逻辑回归模型的输入流“def stream regressionmodel_input_stream”，如图所示。然后，可以将四个传感器数据值的相应时间对齐有序集联合为一系列数据集，以输入到模型中。与“with”关键字一起使用的“select”命令表示跨所有四个传感器数据流的AND-JOIN(与-联合)，并自动完美地时间对齐，以便CEP引擎进行实时地处理。

因此，只需允许用户在两个实时联合选项之间进行选择，转换器和方法就可以将PMML数据输入映射到现实世界的传感器，并关于如何组合、预处理和精确对齐用于预测算法的数据自动生成跨时空连续体的语义。这对于为用户简化抽象级别和简化模型部署工作流来说是一个巨大的好处。如果没有此，模型预测在现场边缘环境中将毫无意义。虽然特定示例使用AND-JOIN函数来组合、预处理和精确对齐来自多个传感器数据流的数据以输入预测算法，但实现了许多其他一流的时间语义(例如，或-联合(OR-Joins)、窗口化(Windowing)、模式匹配、多态函数应用、数学/统计函数、信号处理原语等)，它们跨自动代码生成的任意N个流工作，无需任何应用开发者的努力。现有技术水平没有这样的规定来实际使机器学习模型为边缘处的实时数据流处理做好准备。

PMML规范未能捕获在真实操作环境中的边缘处操作所需的业务上下文。它提供了一种静态规范，相比于实时流送传感器数据，更适合对成批的静态数据集进行操作。例如，它只是表明模型需要来自四个传感器的输入数据产生预测，但没有表明输入数据集“何时”提供给模型的任何信息。需要进一步的规范来定义是在所有传感器产生数据值并且所有值都已接收时提供数据，还是当任何传感器产生数据值时提供数据(在这种情况下，旧值可能用于其他传感器)。在转换后的代码中，定义和指定了模型的输入数据的时间方面以及数据的来源和类型。这个进一步的规范使模型能够在现实世界环境中的边缘处实时处理流送传感器数据。

另一点是，由于用于批量静态数据集的模型是如何训练并转换为通用规范(例如PMML)的，PMML规范仅定义了模型所需的一般性数据输入，而没有考虑在实时操作环境中可以在现实世界中接收此类数据的形式。例如，PMML规范将“temp(温度)”输入数据定义为“双值”类型。然而，在现实世界应用中，产生实际温度数据的温度传感器可以并且可能会使用OPCUA协议，并且它产生的每个传感器数据值可包含大量元数据以及实际数据分组。因此，要使PMML规范模型能够在边缘处针对现实世界数据操作，至少需要包含额外的逻辑来取得模型所需的实际温度数据。相比之下，由于是结构类型化的，因此很容易在传感器数据流中匹配所需的输入数据并将其应用于模型。

220上述将PMML规范转换或转变为等效的示例演示了PMML规范如何被解析以及输入(对于ML模型)如何通过提供大量时间抽象作为一系列相应的数据值选择而映射到现实世界事件。这解决了在实时数据流处理环境中部署ML模型的最大挑战之一。在下一阶段，转换器和方法分析与输入、它们的关系、实际ML算法以及PMML模型的任何后处理步骤相关的各种转换(计算)。该分析可以作为单步执行，但重复多个子阶段，以通过构建执行模型的整体视图来优化代码生成。大多数传统方法采用的方法只是将这些实现为一系列待办事项以供执行，而此处描述的方法采用与编译器类似的非常不同的整体方法。目标不仅是生成语义上等效于PMML版本的代码，而且生成针对边缘计算环境进行运行时优化的代码。在从PMML生成代码的整个过程中，多个子阶段反复应用常量折叠技术、利用SIMD(单指令；多数据)计算、芯片组原子、图形优化和并行代码执行(只要适用)。

再次比较相应的PMML规范和转换后的代码，PMML规范将输入的数据转换指定为预处理步骤，这对于ML模型非常常见，然后再将数据提供给ML模型。数据转换包括对每个输入字段进行平方，然后将每个输入字段与作为ML模型训练的一部分计算的指定系数相除。在相应的<DerivedField>部分中，针对温度、直径、速度和张量的每个传感器数据输入，单独并串行地执行数据转换。

采用单步多子阶段分析和代码生成，多个串行实现的数据转换可以实现为一行代码，其对数据集并行地进行操作并内置有优化。这在代码中示出为数据定义“def local regressionmodel_transformed_stream＝...”，其中“data”使用平方和除法函数进行运算，并且被执行运算的数据包括由命令“select data fromregressionmodel_input_stream”选择的并行数据值的串行集合。

在这个示例中，单步多子阶段分析导致优化的代码，其中首先生成中间本地流，其利用SIMD(单指令多数据)同时对所有输入执行相同的平方运算(a^2)。然后将数组的结果数据值除以相应的索引系数({100,25,10,8.5})。优化是通过两个嵌套的函数应用“map2”和“map”实现的。“map”对包含数据值“temp”、“diam”、“tensions”和“speed”的记录进行操作，函数为“fn is a:real->a^2”。在“map”中，对每个记录项进行平方，并生成SIMD指令，使边缘平台的CPU按照单条指令对所有记录项执行此函数。“map2”对“map”的输出、系数记录{100,25,10,8.5}和描述变换(除法)“fn is p:real,q:real->p/q”的lambda进行操作。一旦加载了两个数组或记录，除法函数可以作为单个CPU指令对数组的相应数据值并行执行。这优化了整体计算并使其在实时流送计算环境中执行得更快。

这与传统方法有很大不同，传统方法只是对记录的每个元素(例如，在循环中)迭代地重复相同的操作。在传统方法中，记录或数组的每个元素将单独被平方，然后除以各自的系数。这种方法包括由CPU重复执行的长多步指令集，这是低效和耗时的。相比之下，等效的经转换并优化的代码包括CPU在运行时执行的单步指令，这使得执行速度更快，这是实时地处理连续传感器数据流所必需的。

由转换器和方法执行的优化的另一个示例是对用户的透明数据表示。提供张量(N维)和矩阵(二维)作为一流类型，操作原语以非常相似的方式公开。这允许将最佳形式的内部数据表示用于每个数据存储库实例，而无需进行必要的来回转换，例如Python机器学习库通常需要执行的转换。数百个其他这样的优化和智能技术层也可以包含在PMML到转换器和方法中，以利用的固有优势，如本文和本受让人的专利和申请中所描述的(以引用方式并入本文)。

本领域技术人员将理解，虽然上述示例描述了从PMML到的转换，但相同的方法也可用于从各种其他广泛采用的机器学习库和格式(例如Tensorflow、ONNX、XGBoost和MLPACK)生成代码。例如，可以使用XGBoost在R或Python中训练模型，然后将模型导出为XGBoost序列化格式。然后可以将其转换为语义等效的经边缘转换并优化的程序，直接为最常用的ML库提供接口。

主要参考图10并且如前所述，转换器和方法还可以结合相对于模型的PMML版本而对生成的代码模型进行验证，以更好地确保准确性。转换器和方法的这一方面在图10中称为PMML代码库1010。PMML代码库解析PMML模型，生成功能和语义上等效的代码模型，并相对于PMML模型来验证代码模型。PMML代码库包括模型验证解析器1020、模型验证管理器1030和比较结果组件1040。PMML模型最初被输入到模型验证解析器。模型验证解析器解析PMML模型中<Inline Table>节点所指示的模型验证标签，根据<Mining Schema>节点生成输入数据，根据<Output>节点从PMML模型生成预期输出数据。然后模型验证解析器分别处理输入数据和预期输出数据，并以调试器格式生成输入和预期输出数据。这样做是为了便于将生成的代码模型所产生的结果与根据PMML代码模型的预期输出进行比较，如下文进一步所述。模型验证解析器然后将生成的代码模型、格式化的调试器输入数据和PMM模型验证预期结果发送到模型验证管理器。

模型验证管理器的主要功能是管理各种组件之间的通信。模型验证管理器接收来自模型验证解析器的输出，并将生成的编码模型和调试器数据输入发送到调试器，例如通过网络套接字，例如WebSocket VDB 1050。调试器是交互式程序，可用于编写、编辑、测试和调试脚本。调试器可以对提供给调试器的输入数据编译和执行要测试的脚本，并且调试器可以输出结果以供分析。在这种情况下，调试器对调试器输入数据执行生成的代码化模型，并通过网络套接字将结果返回给模型验证管理器。模型验证管理器依次将调试器结果转发到比较结果组件。

比较结果组件将由调试器执行的生成的代码模型所产生的输出结果与来自PMML模型验证标签的预期结果进行比较，并将报告发送回模型验证管理器。模型验证管理器将来自调试器的代码模型的输出结果与预期的PMML模型验证结果进行比较，并生成报告1060，该报告指示生成的代码化模型是否产生了预期结果、它产生的实际结果、以及它是否通过或失败。模型验证管理器然后将报告发送到边缘管理器547(见图5和图9)，例如通过网络套接字，例如WebSocket FHM 1070，在边缘管理器处，报告可以显示在用户界面上。可以理解的是，虽然上述验证方法是针对中间PMML形式的模型的转换进行描述的，但同样的方法也适用于对高级模型语言(例如Python)的模型的转换进行验证。

再次主要参考图9，在对云创建的ML模型进行边缘转换或“边缘化”(包括标准模型和深度学习模型)之后，该模型可以通过互联网或经由其他网络或连接被部署到示例边缘平台406、609。模型从云到边缘平台的部署在边缘的边缘管理器547和云软件平台的云管理器552(也参见图5)之间进行管理。在这点上，虽然图9将云管理器552示为云412的一部分，而边缘管理器547作为边缘平台406、609的一部分，但应理解，云管理器和边缘管理器中的每者可以驻留在其他网络中的其他计算平台上并执行，并可以彼此通信以及通过互联网或其他网络连接分别与云和边缘平台进行通信。

经边缘转换的模型可以直接从云部署到边缘，或者可以从云部署到应用商店637(也参见图6)并从应用商店部署到边缘平台。如前所述，优选使用SDK 564(图5)对模型进行容器化，以便它们可以部署到具有各种不同计算和其他资源的各种不同边缘和其他平台并在其上执行。

部署到示例边缘平台406、609的经边缘转换的模型由机器学习软件平台804在平台上管理。机器学习平台可以通过合适的用户界面(UI)访问，并结合了用于选择一个或多个标准或自定义机器学习模型、设置模型参数、训练模型、使模型在现场传感器数据上执行、停止模型执行、导出模型和模型配置、以及根据需要评估、验证和更新模型的功能。经边缘转换的模型在CEP引擎上高效执行以生成预测和推理，这些预测和推理可以由边缘应用单独使用，或者可以与其他模型、应用、分析表达和实时来自现场流送传感器或其他数据的其他生成的其他推理、分析结果和智能结合使用。预测、推理和其他分析结果和智能可以通过数据发布器570从边缘平台传输到云412，以及传输到其他边缘平台实例、传输到本地网络或传输到其他网络。它们还可用于确定是否在本地网络中针对控制系统、机器、传感器和设备523等采取动作，或提供信息、警报、警告或其组合等，例如提供到本地网络的管理系统用户界面908。

基于边缘的ML模型的迭代闭环更新

一旦经边缘转换的ML模型部署到边缘平台并开始对实况传感器数据进行操作，可能希望定期评估模型生成的预测、推理和其他输出的准确性，并根据需要迭代地更新模型。模型性能随时间下降并不罕见，可能有多种原因，包括传感器输出随时间的变化或下降、当地环境的变化等。模型性能的下降可能表现为从数据生成推理的延迟增加和推理准确性的降低。

参考图8和图9，边缘平台406、609和云平台412之间的闭环布置提供边缘平台上ML模型的周期性评估和迭代更新。预测、推理和其他模型输出、生成预测和推理的传感器数据以及其他分析结果可以从边缘平台406、609定期传输到云平台412。其他信息(例如企业参考数据802)也可以传输到云。此类信息可用于评估预测准确性或根据所需规范检查模型输出。

将此类数据和信息传输到云可以在边缘平台或云处手动发起，或者可以自动触发，例如基于预定时间段消逝，或检测到模型输出的变化超过预定值。例如，可以在边缘平台的CEP中对模型生成的推理流执行所选择的实现逻辑、数学、统计或其他功能或其组合的分析表达。分析表达可被选择以响应于所选择的输入传感器数据有效地定义什么构成模型的不可接受的漂移水平或准确度降低，并跟踪模型输出以确定准确度是否降低或漂移超出可接受限度。例如，分析表达可以确定推理随时间的统计特性，例如均值、平均值、统计显著范围或统计方差。表达可以将模型输出与所确定的特性或与存储的或以其他方式提供的定义可接受限度的值进行比较，从而确定模型的准确度是否已经漂移或降低了不可接受的水平。如果是这样，则边缘平台可以自动采取动作。这种动作可以包括例如记录输入到模型的一定量的原始传感器数据以及可能响应于这种数据的相应模型输出，并将其发送到云以重新训练/重新评估模型。预测、推理和任何其他数据可以通过互联网或通过其他合适的网络或其他连接传输到云。

在云平台412上，传输的预测、推理、数据和分析结果以及其他信息可以聚合在云存储库573中。云存储库中的所传输的数据和信息然后可以由数据挖掘、模型更新和验证组件902、904使用和操作以评估基于边缘的模型结果的准确性并根据需要或期望进一步调整基于边缘的模型。例如，在与从边缘平台传输的相同类型的大量数据和信息上训练的基于云的模型可以对从边缘平台传输的数据和信息进行操作，并生成诸如推理之类的输出。可以将基于云的模型生成的输出与基于边缘的模型生成的输出进行比较。如果确定了不可接受的变化，则可以在云中生成基于边缘的模型的更新版本，例如通过改变模型算法的权重因子、系数或参数。更新的基于云的模型然后可以由如上所述的边缘转换组件906边缘转换并且重新部署回边缘平台。

闭环布置还有益地提供了一种机制，用于开发多个ML模型，部署到边缘，并比较最佳性能和准确性。在一个示例工作流中，一个或多个不同的ML模型(可能具有不同的假设和参数)可以使用相同的聚合传感器数据在云中生成和训练。然后将模型部署到边缘并在边缘处的实况传感器数据上执行。模型产生的结果被发送回云并在云中进行评估，以确定哪个模型产生最准确的结果。然后可以选择最准确的模型来使用。在使用中，所选模型从实况传感器数据中生成的推理和预测会重复发送到云进行评估。在云中，模型可以被更新，例如通过改变权重因子、系数或参数。更新后的模型或权重因子或其组合、系数或参数然后被重新部署到边缘以替换当前模型、权重因子、系数或参数。因此，基于边缘的模型不断学习，随着时间的推移变得更好训练和更智能，并且可以产生非常高的保真度结果，与人类产生的结果相等，有时甚至更准确。云412和边缘平台406、609之间的这种连续迭代闭环布置因此有效地在边缘处提供AI。如果需要，该布置还可用于实现机器学习作为服务。

动态无中断ML模型更新和替换

与上述迭代闭环机器学习系统相关的本发明的另一个特征是在实时数据流处理期间提供动态无中断ML模型和权重更新。在生产中部署ML模型的最大挑战之一(尤其是在诸如资源受限的IoT环境的实时流送环境中)是模型升级和更新。通常，如果要将新模型或更新模型部署到边缘平台以在实况传感器数据上执行，则需要关闭现有模型的执行，同时将其替换为新模型或更新模型。类似地，如果希望在边缘平台上就地更新模型而不是替换它，例如通过更新某些权重或系数的值，则需要在进行更新时关闭模型的执行。在任一情况下关闭模型的执行都是不希望的，因为只要模型关闭，模型对实况数据的实时地处理就会丢失。在关闭期间，边缘平台可能因此错过数据所指示的某些发生。此外，在某些情况下，模型处理数据的中断可能会影响执行恢复时模型产生的推理的准确性。

另一种方法可能是与现有模型并行地部署和执行新模型或更新模型，然后取消现有模型。然而，这种方法效率低下，不适合资源受限的边缘计算环境。虽然这种方法可能适用于具有基本上无限计算和存储资源的分布式云计算环境，但它不适用于通常只有有限计算资源和连接性的分布式IoT边缘环境。在该环境中，并行部署和执行方法根本不起作用或无法扩展。

为了在实时数据流处理期间实现动态无中断ML模型和权重更新，提供了响应实时数据流中语义的有状态(stateful)子系统。有状态子系统提供动态地替换和更新边缘平台上现有模型的能力，而不会中断或扰乱模型对数据的实时处理和推理的输出。该子系统与实时传感器数据流语义耦合，而不会中断现有的流送数据流或现有模型对其的评估。

有状态子系统通过读取新替换模型并将其耦合到与现有模型耦合到的相同实时数据流的相同语义来实例化替换模型的实例。替代地，子系统实例化现有模型的实例，读取要应用的新权重，并在将实例化和更新的模型耦合到与正被更新的现有模型相同的数据流的相同语义之前更新模型实例化版本中的权重。可以从云、另一个存储库或从流中读取替换模型或权重或两者。在任一方法中，当新模型或更新模型上线时，现有模型对数据流的处理都不会中断。

下面的表5提供了以FogHorn的语言表示的示例，该示例使用标识为actor_t(感知器)的有状态子系统来实例化模型更新，例如与基于TensorFlow的神经网络模型相关联的更新权重。在此示例中，该模型正使用来自交界处摄像机的视频馈入作为输入，生成对特定铁路道口即将发生的车祸的持续实时地预测。可以理解，在这种关键应用中，与许多其他应用一样，重要的是能够替换或更新在实况数据流上运行的模型，而不会中断数据流的实时处理或模型产生的一系列实时预测。

表5

“def stream video_input”语句将模型的输入数据流定义为来自交界处摄像机的实时连续视频帧流。帧被指定为宽*高为720*480像素。指定了三(“3”)个通道来描述红色、绿色、蓝色(意味着帧是彩色的)。

语句“def stream ml_model is{name is str,id is int}”定义了表示现有当前机器学习模型的流。将机器学习模型本身定义为随时变化的连续流(类似于不断输出新值的传感器)是实现当前模型的无中断动态更新或替换的关键。虽然经过训练的模型通常只是可以对输入数据流进行操作的单一的静态工件或实体，但为了计算目的将模型本身定义为可以随时更改的序列化流完全改变了模型。通过将模型本身表示为流，实时数据流语义可用于推理模型本身。因此，本文描述的系统和方法不是将模型描述为静态工件(这是在其他系统中完成的)，而是将模型视为连续流，该连续流随时可能发生变化并且在边缘计算平台上与模型正在处理的一个或多个输入数据流一起不断地流送。

在“startup”块中，通过使用模型的初始版本初始化流“my_model”来使用模型的初始版本初始化“ml_model”流。在此示例中，模型初始版本的名称是“crash.pb”，“101”是模型的唯一标识符。因此，模型的实际存储方式，无论是在磁盘上还是在内存中，对于用户来说都是完全抽象的。这允许一种与设备、系统和计算机无关的表示，因为它可以以任何可能的方式实现。

语句“def stream ml_actor”定义了流“ml_actor”，该流由作用于“ml_model”流的actor“tensorflow_actor”生成。“tensorflow_actor”是内置的原语，它识别和理解TensorFlow的语义，并利用其运行时模型来执行基于语义的计算。它建立在称为“actor_t”的有状态子系统上，该子系统被设计来理解流语义。actor_t子系统在嵌入任何任意流计算功能方面提供了灵活性，但仍封装了所有一流的时间流送功能。当actor_t子系统检测到流“ml_model”中的变化时，“tensorflow_actor”被该子系统实例化。

如上所述，模型流“ml_model”最初表示启动时的初始模型“crash.pb”。此后，随着初始模型更改，“ml_model”代表任何时间点当前存在的模型。“tensorflow_actor”被实时地实例化，以响应“ml_model”流中检测到的变化。“tensorflow_actor.load()”从流“ml_model”中读取初始的“crash.pb”或后续更改的序列化模型，并构建自己的存储器内状态和执行子系统，该子系统实现从流读取的模型以及任何新的更改或更新。然后，该子系统生成代表新模型或更新模型的流“ml_actor”。模型流(首先包含先前的模型，然后立即包含更新模型)与模型要处理的(一个或多个)数据流对齐。这种将模型更改与正在处理的输入数据流一起实时地向下游传播的方法因此允许模型在更新或替换模型时继续处理输入数据流，而无需关闭或中断。每次在代表当时模型的流中检测到变化时，都会重复这种将模型变化与输入数据流一起向下游传播的方法。

需要注意的是，构造器actor_t优选地也被表示为具有定义为参与者的类型的流。这种允许将更丰富的构造器表示为流类型的方法允许将流送语义扩展到更高级的抽象并提供紧凑的表示。

因为“ml_actor”是由“tensorflow_actor”实时地构建的新模型或更新模型的流表示，所以它可用于基于来自相机的视频输入流执行预测。这些预测在“def streampredicted_crash”语句中定义的“predicted_crash”流中表示。语句的“(latest ml_actor).predict(input_data)”和“select data from video_input”部分共同构成了一条指令，以便只要视频输入流继续就继续接收视频输入流，并使用“ml_actor”流中表示的模型的最当前版本连续产生预测流。

只要继续从“video_input”流接收数据，根据示例的代码将导致“ml_actor”流中存在的模型的最新表示被用于在数据被接收时对接收到的数据执行预测。可以理解，由于参与者“ml_actor”和模型“ml_model”都表示为连续流，因此可以在任何给定的时间点将新模型插入到流中并且可以根据需要或期望多次插入，而不会中断处理传入的视频数据流或模型产生的连续预测流。每次更新或替换当前模型时，更改将向下游传播并反映在“ml_model”流中。这进而将触发“ml_actor”流中的更改并实时原子地构建新的模型状态。模型预测将只是继续使用新的输入视频，就好像什么都没发生过一样，但是，新模型将生效。因此，在一个时刻，旧模型被用来基于输入数据流产生预测，因为它在那个时刻存在，并且在紧随其后的另一个时刻，新的更新或替换模型被用来基于该时刻的输入数据而产生预测。

因此，如上所述，将理解本文描述的系统和方法的关键方面是在预测连续体中不存在“弹开(blip)”。输入数据流中的每个数据点都会针对每个预测进行评估。这显然是关键任务实时ML模型非常理想的属性。此外，除了将期望的模型更改或新模型插入到输入流中之外，利用这里描述的系统和方法，模型可以被无缝地更新或替换并且无需人工干预。

还应当理解，对于诸如前述示例中描述的实际系统，非常重要的是，无论多少次或何时可能需要或期望更新或替换机器学习模型，实时地预测流都不会中断。与示例相关的几行程序实现了该目的。因此，在所描述的系统和方法中，其中模型被表示为本质上被设计为随时间改变的序列化的流，并且其中对当前模型的更改作为链式反应随被处理的输入数据流一起向下游传播，对现有模型的更改可以在不会扰乱或中断模型对输入数据流的实时地处理或模型在更新或替换时产生的连续预测流的情况下进行。

还应当理解，本文描述的系统和方法可以支持并涵盖通过将新模型或更新模型插入模型流来动态更新当前机器学习模型的多种方式。可以通过将新配置手动部署到模型流中来完成更新。可以从上游分析或机器学习模型触发更新。可以通过适当的网络连接将云中新训练模型的自动更新推送到边缘。也可以由云或边缘的版本控制管理系统发起更新。

无缝模型链接、编排和管线化

与上述迭代闭环机器学习系统相关的另一个特征是提供多个机器学习模型的无缝链接、编排和管线化。

除了非常具体和狭窄的用例外，大多数实际的IoT部署都涉及多个ML模型，这些模型被部署用于执行监控、预测性维护和其他功能。因此，典型的IoT环境可能涉及部署数十到数百个传感器并执行至少几个ML模型(如果没有更多的ML模型的话)来处理传感器产生的数据流。

对于可以部署哪些模型、可以使用哪些数据以及如何将它们相互链接以产生所需结果，存在多种可能性。在许多现实世界部署场景中，多个ML模型在逻辑上相互构建为分层堆栈，这些模型在原始传感器数据和来自其他模型的信息上运行。在其他场景下，将多个竞争模型部署在一起并观察它们的结果以确定哪些模型表现更好或以减少来自一个模型预测的偏差并将其与实际事件进行比较。这样的场景会导致各种模型的链接和编排的依赖图相当复杂，而开发特殊的基础结构来维护此链接和编排以达到预期的结果是一个相当令人生畏的问题。事实上，即使是时间的流逝单独也有可能触发对于以某种方式链接模型或改变现有链接布置的需要。

在如上所述的动态环境(包括多个模型、连续模型更新、模型的复杂管线以及它们应该相对于彼此运行的顺序)中，本文描述的系统和方法利用了实时数据流系统和方法本身的反应性质，并依赖于“数据流”本身作为有效的链接机制。因此，本文描述的系统和方法将整个运行边缘系统/设备设想为具有连续无限流的数据流图。

设想各种流可以包括数据、时间令牌的传递、显式控制触发器或其他信息项，所有这些信息都捆绑到称为“主题”的单个抽象层中。每个主题属于唯一的命名空间，其中是共享数据、时间传递令牌、控制信号或其他信息或其组合。主题可以包含一个或多个子主题。主题和子主题例如经由发布-订阅基础结构通过数据总线访问。发布-订阅基础结构虽然已知用于其他目的，但据发明者所知，从未有人建议将其用作无缝模型链接和模型管线机制。

在当前的链接、编排和管线化系统和方法中，所部署的一个或多个ML模型通过名称绑定到一个或多个主题和子主题作为输入、输出、输入或输出。各种模型和主题之间的绑定作为输入和输出或两者例如允许数据、信号和其他信息通过数据总线在发布-订阅基础结构上经由公共主题而在模型之间进行传送和共享。因此，绑定到一个或多个主题的一个或多个ML模型中的任何一个都可以向任何或所有主题发布数据或信息，并且一个或多个其他ML模型中的任何一个都可以订阅任何一个或多个相同的主题并使用此主题来组织数据流或在流中进行控制。

相同的系统和方法可用于创建涉及任意数量模型的任何任意数据链或控制流，而无需明确或具体地创建或设置各个模型之间的链。这种抽象级别有助于在实现个体模型时简化用户的思维，以便用户只需将模型视为仅包含一个或多个输入、计算阶段和绑定到一个或多个所需主题的输出。用户无需考虑连接各种其他模型的哪些输入和输出以及连接顺序。使用这种方法作为构建块，人们可以任意构建相互连接的传感器链或其他数据生成设备、以及基本上无限复杂性、数量和大小的机器学习模型的系统。

图11是一个图表，图示了将经边缘转换的ML模型和分析应用于在网络边缘处而不是云中流送来自本地网络的传感器数据的显著优势。图表902的上部分图示了在一段时间内由本地网络中的压力传感器产生的示例性原始吸入压力数据流。在所表示的时间段内，对于具有典型数据速率的传感器，由传感器生成并在边缘处实时地接收的数据量可能在千兆字节(GB)。

假设从本地网络到云的互联网连接即使可用，带宽也可能有限或可能很昂贵。因此，通常对大量本地网络传感器数据在被发送到云之前进行下采样以减少要传输的量。如图所示，在传输之前对数据进行30倍下采样并不是不典型的。图表904的下部图示了来自上部902的原始传感器数据流的30倍下采样版本。下采样将传输到云的传感器数据量从千兆字节减少到兆字节(MB)。然而，下采样也会对数据的保真度产生不利影响，并对机器学习模型和其他分析产生的结果产生不利影响。

例如，上部图表902的传感器数据流显示了许多实例或事件，其中测得的吸入压力从每平方英寸40磅急剧下降到每平方英寸50磅范围，再到每平方英寸大约0磅到大约10磅。在一个实例906中，下降的持续时间很长并且可以指示泵的操作的当前或未来问题。然而，下降的开始和持续恰好与30倍下采样的采样率和占空比一致。因此，该事件没有反映在下部图表904所示的下采样数据流中，并且不会被机器学习模型或对下采样数据流操作的其他分析检测到。

在另一个实例908中，上部图表说明了两个持续时间非常短的压力下降的发生，这可能反映了由于振动或其他外部影响而导致的正常传感器波动，并且对于泵操作而言并不显著。然而，这两个压力下降恰好发生在一个时间窗口中，在此期间它们都被30倍下采样捕获，因此导致压力下降事件的误报(false-positive)反映在下部图表中所反映的下采样数据流中。这种误报会导致机器学习模型或对下采样数据流进行操作的其他分析在没有压力下降时检测到与泵相关的显著压力下降事件，这可能导致模型产生不准确的预测或推理。

图12是一般地图示机器学习模型软件平台804的使用的功能图。机器学习模型软件平台可以经由浏览器1102(例如Microsoft Explorer、Google Chrome或MozillaFirefox)通过分配的IP地址和端口号或URL访问。

机器学习模型软件平台向浏览器呈现包括工作流列表的用户界面。每个工作流包含一个或多个要操作的传感器数据流以及一个或多个以期望的顺序针对流执行的分析表达、应用、机器学习模型等以实现期望的输出或输出集。因此，工作流定义了要针对传感器数据流采取的完整动作集，包括：通过表达、应用和模型进行的摄取、富集、处理和评估；要采取此类动作的顺序；各个动作的输入和输出；以及要公布的最终输出；以及要采取的动作。工作流和工作流的各个组件可以接收其他工作流或工作流组件的输出作为输入，并且可以将输出作为输入提供给其他工作流或工作流组件。通过这种方式，用户可以选择性地链接工作流以创建复杂的处理方案。

用户可以从列表1104中选择工作流以查看构成工作流的各种组件的细节，其可以包括一个或多个机器学习模型。用户可以编辑与已经是现有工作流一部分的机器学习模型相关联的参数，还可以识别新机器学习模型并将其添加到现有工作流中。例如，用户可以使用用户界面输入某些机器学习模型信息和参数1106，例如模型类型(例如，回归)、算法类型(例如，决策树)和算法参数。这些参数存储在软件平台中。

用户还可以使用界面将训练数据1108上传到软件平台，以允许在边缘处训练所选工作流的模型。例如，可以将训练数据以.csv文件的形式上传到软件平台，该文件包含数组，其中具有数据输入和输出名称的列表以及相应的数据值。用户可以使模型在训练数据上执行以在边缘处训练模型。这可以作为在云中训练模型的替代或补充来完成。此外，如上所述，模型在训练数据上执行的结果可被发送到云以进一步调整模型。

用户还可以使用界面来设置和启动所选工作流的一个或多个模型以在实况传感器数据上执行。在开始对实况传感器数据执行模型之前，用户首先使用界面将传感器数据主题和字段绑定到模型输入1110。优选地，用户界面显示传感器数据主题和字段名称或标签的列表以及所选模型的输入名称或标签。然后用户选择相应的传感器主题和字段以及模型输入来绑定或关联它们。用户还将所选模型的输出绑定到数据总线主题1112，以便在边缘平台上发布模型的输出以供应用和其他使用。优选地，为此目的，用户界面显示数据总线主题名称的列表。用户只需从列表中选择所需的数据总线主题即可绑定模型输出。绑定与模型一起存储在平台中。

一旦模型输入和输出分别绑定到传感器输入主题和数据总线输出主题，用户就可以对实况传入传感器数据启动模型的执行。用户界面列出了要针对工作流采取的可用动作，包括删除、开始、停止和编辑。为了启动对实况数据执行的机器学习模型，用户首先选择包含模型的工作流，然后选择“开始”1114。用户可以通过选择工作流然后选择“停止”在任何时间停止机器模型的执行。

当模型作为选定工作流的一部分在执行时，它会产生推理、预测等的连续时间序列流，作为根据模型定义从流送传感器数据输入和任何其他输入导出的输出。模型输出被发布在边缘平台的数据总线532(图5)上，并且可以在包括同一工作流(模型作为其一部分)的组件的应用和分析表达以及包括其他工作流的组件的应用和表达中被访问和使用。如前所述，模型输出还可被存储和聚合在边缘平台上或传输到云，或两者都进行。

边缘管理器547还可以通过浏览器(例如浏览器1102)访问，并且由用户使用以在边缘平台上实现和管理机器学习模型作为配置边缘平台的一部分。边缘管理器包含呈现给浏览器1102的用户界面。该界面显示可用于选择和添加应用(例如机器学习模型软件平台804)和机器学习模型到边缘平台的边缘管理窗口。

边缘管理窗口显示多个选项，包括“添加应用”和“添加模型”。为了将机器学习模型软件平台804作为应用添加到边缘平台，用户将选择“添加应用”。然后，边缘管理器从用户接受以下项目作为输入：或者是来自用户计算机的包含此app的文件(例如.yml格式的文件)的名称、边缘用户可以访问应用的URL，或者是从边缘管理器维护和显示的列表中对之前添加到边缘管理器的app的选择。如果输入或选择了文件名，则文件在必要时通过互联网或其他网络连接上传或传输到边缘平台。替代地，应用的URL被保存在边缘平台上，并由边缘管理器与应用的名称相关联，从而允许远程访问应用。

为了将机器学习模型添加到边缘平台，用户将选择“添加模型”。然后，边缘管理器接受模型的名称作为输入，并将包含模型的文件(例如.xml或.pmml文件)从用户的计算机上传到边缘平台。替代地，用户可以从先前添加到边缘管理器的模型的列表(边缘管理器维护并显示该里诶列表)中选择要添加的模型。为了准备好在边缘平台上执行机器学习模型，用户界面标识并显示连接到边缘平台的传感器的数据主题以及模型输入数据流的名称。用户以与上文关于机器学习模型软件平台所描述的基本相同的方式将模型的输入数据流绑定或关联到传感器数据主题。此后，机器学习模型可以被添加到工作流中并且被启动以如本文所述在实况流数据上执行。

示例性实施例的前述描述仅用于说明和描述的目的。其中的任何标题仅为方便起见。前述描述并非旨在穷举或将本发明限制为所描述的一种或多种精确形式，并且在不脱离本发明的精神和范围的情况下，根据本文的教导可以进行许多修改和变化。选择和描述这里的实施例是为了最好地解释本发明的原理及其一些实际应用。该描述将使本领域的其他技术人员能够以适合特定用途或应用的各种实施例和各种修改来最好地利用和实践本发明。因此，本发明的范围旨在由以下权利要求限定。