浅谈工业物联网应用的数据存取技术

制造业寻求自动化设备和应用程序的集成，最好的榜样就像即插即用的网页浏览体验那样，完全不用通过人工来连接“物”，即插即用。为了达到这一理想状态，包括工业自动化的许多专家和从业人员投入到这一复杂的挑战中。然而历经多年，到目前为止任何参与智能制造和工业4.0的人都知道，绝大部分的实践还是碎片化的，局限于一些狭窄领域，更遑论跨领域的数据存取的互操作性。                                                                                                                                                                                                                                       本文作者彭瑜，毕业于清华大学热能工程系，教授级高级工程师，PLCopen中国组织名誉主席，中国自动化学会仪表和装置专委会名誉常务委员，国务院特殊津贴获得者；长期从事工业生产过程自控系统的设计、现场总线和工业通信在控制系统的应用研究工作。       统而言之，目前在世界范围内还没有机构和组织能提供一种经过验证的标准化方法，市场上的工业物联网的产品也没有办法选择一套公认的标的技术。换句话说，为实现这一基础性问题的标准化还是在路上。

好在对此现状表示不满和忧虑的大有人在，有许多人和组织正在谋求突破。最近就有令人高兴的消息传来，微软的Standards, Consortia & Industrial IoT总架构师向美国ISA的专业网站透露，微软与西门子合作率先使用可被发现的数据模型（如OPC UA和W3C物联网WoT标准），简化并实现了工业现场设备数据标签的自动变换。这一改工业物联网、工业互联网的项目中最花费时间又容易出错的任务的现行做法，即：从手动将没有标准化或没有可被发现的数据模型的工业设备的数据标签，自动变换为类似OPC UA这样的标准数据的操作，从而开辟了即插即用，以便于在边缘或云中进行进一步处理的前景。  

Vol.1

以互联网为师

成功解决互操作性已经有了先例，大家所熟悉的网页浏览，调制解调器是互联网的网关。购买PC后，将其带回家，标准化的好处立竿见影。首先，开箱即用的个人电脑通常都有一个以太网端口。PC连接到网络调制解调器后，通过DHCP（Dynamic Host Configuration Protocol）获得IP地址，并发现自己的网络网关。然后，它会发现自己的域名系统（DNS）服务器是什么，并开始访问来自全球各地的广泛信息。所有这些机制都通过一个网关自动激活；对于大多数用户来说，它是一种相当于魔法的技术。历史的经验证明，这种全球网络只有在市场围绕特定标准进行整合时才有可能实现。那么，人们渴望着在运用工业物联网（IIoT）也可以使用类似的魔法技术的时候，是不是也应该思考选择什么样的标准化方案和路径才有可能跨出成功的一步呢？我们可以预言，像IIoT这种需要在全球形成的网络，只有在市场围绕特定标准进行整合时才有可能实现，否则就是一个实现不了的“承诺”。   如图1所指出的在IIoT的许多服务和功能（诸如历史数据存取、报警和通知、下达命令和控制、数据操作、数据分析和预测）中，实时数据访问是最最基础的，通常也称为设备或流程远程数据采集。这种类型的数据通常被归类为时间序列数据，是非事务性（non-transactional）的，以真-假、数字或文本的形式存在。可视化或测量工厂层上正在发生的事态通常是数字化转型的第一步。特别是从大规模地将各种设备从不同的地域集成接入IIoT，跨越数据互操作的鸿沟的重要性就益发显现。如果我们运用IIoT最直接的用例即数据访问有了标准化的解决方案，那么工业物联网给制造商带来了巨大的挑战就有了成功的基础，而不会出现由于解决不了从工厂现场存取数据这方面的问题，常常成为一些数字化转型计划的拦路虎，以至于胎死腹中。

图1  工业物联网的各种功能 （图源：IEB网站）

Vol.2

MQTT和OPC UA

没有明确定义数据存取的互操作性

智能制造利用工业物联网众多目标之一是在企业中纳入新的信息产生方和/或信息使用方时不需花费集成成本。简化集成主要是通过在通信层和信息层实现一些知名标准的产品来实现，譬如OPC UA和MQTT。但是，这两个标准是否足以实现数据存取的互操作性呢?

目前MQTT已成为实现“一次提供数据；可以到处分发”（provide data once; distribute everywhere）的架构。OPC基金会于2006年发布了第一个OPC UA规范，其中包括许多其他连接功能中的数据存取功能。其优点包括启用非windows设备、具有标准数据类型定义的可浏览地址空间，以及具有死带过滤条件的长轮询机制。OPC UA在制造商中变得流行，因为除了现有客户端-服务器范式，在2018年还增加发布-订阅协议，将Pub/Sub连接添加到规范中，包括无代理（broker-less）协议的以太网和UDP和有代理（brokered）协议的AMQP和MQTT。OPC基金会继续实现互操作性的目标，通过配套规范定义了标准对象类型，每个规范都利用核心数据定义来构造标准对象定义。

关于数据存取的互操作性，OPC UA和MQTT并未明确定义。如图2所示，MQTT仅定义基本通信协议，其余所有堆栈都未定义，这些未定义的堆栈在图中用红色标注。这就造成选用MQTT时信息使用方为集成应用平添了沉重的负担。

信息使用方面临的集成障碍包括：熟悉信息产生方实现的主题路径，以及确定应用程序是否可以通过最后遗嘱功能监视信息产生方的健康状况。

另外的挑战有：选择使用哪种QoS级别，信息产生者是在固定的时间间隔上发布还是仅在更改的数据上发布，等等。对集成商来说更可怕的是MQTT没有传输数据的定义，因此信息使用方的应用程序不得不适应设备选择的编码方案、数据类型和对象定义。总之，MQTT仅仅定义数据存取模型中的通信协议层，在通信层以上的各层次均未定义的事实形成了如下后果，即如果选用MQTT是远远不能满足数据存取的互操作性目标的。

OPC UA在数据存取模型的每个级别上都实现了标准化。虽然每一层的定义都优于其他技术，但问题出在在模型的每一层级其规范的组合都包含许多选择（见图2）。考虑到过多的通信协议、编码方案、数据类型和对象定义，简单地将OPC UA的信息使用方连接到OPC UA的信息产生者方并不能保证数据存取的互操作性，因为每个应用可能会在堆栈上选择不同的选项。集成商必须仔细评估信息产生方的设备在每一层实现了哪些选项，并确保它与信息使用者方应用程序的功能相匹配。或者相反，集成商将了解信息使用方应用程序的功能，并不得不限制它可以使用的OPC UA产品的范围。由此可见，如果目标是互操作性，指定OPC UA是不够的。

图2  MQTT和OPC UA的协议栈 （图源：IEB网站）

Vol.3

OPC UA over MQTT

开辟了新路径

或许OPC基金会已开始认识到，虽然在每一个层面有多种技术规范提供选择可以增加灵活性，但其带来的负面影响却是增加了集成的成本和推广的困难。于是，在2022年2月宣布，包括亚马逊AWS、谷歌Cloud、IBM、微软、SAP和西门子六家云服务提供商有些在目前的产品中支持基于OPC UA over MQTT，有些会在他们的开发路线图中支持OPC UA over MQTT。这一声明标志着这六家重要企业将与OPC UA over MQTT组合兼容。更令人印象深刻的是，这一声明标志着企业内部多云架构的可能性，允许用户无缝地将数据从一个云供应商转移到另一个云供应商，实现云到云的互操作性。

OPC基金会在2022年4月的OPC国际日上指出，OPC UA over MQTT已有数千种实现。 对于需要识别OPC UA Pub/Sub技术的信息使用方应用的终端用户和集成商，OPC基金会于2022年6月创建了一个市场，作为一个可供公众访问的网页，允许基于功能、传输、应用配置文件和许多其他标准进行筛选。问题在于虽然已经保证了普遍的市场支持，但没有宣布任何OPC UA over MQTT产品在OPC市场上市的时间表，包括来自六家云服务提供商的产品。对于需要商业产品的终端用户和集成商来说，了解市场上可用的产品仍然是一个挑战 与此同时，OPC基金会正在为构建语义语境的数据连通性做出努力。OPC UA FLC（现场级通信）计划正在传感器、执行器、控制器、企业和云之间创建开放标准语义语境的数据连接通信解决方案，满足工业自动化、工厂自动化和过程自动化的所有要求。

OPC UA FX继续取得快速进展，将最基本的工业通信现代化，并将主流计算数据概念推向工业边缘。OPC UA现场级通信（FLC）计划目标包括：在供应商、平台以及目前尚不可知的范畴之间构建安全可靠的通信，实现从传感器到企业及其他领域的互操作性。OPC基金会生态系统是统一的，由工业、IT、物联网（IoT）和云组织组成，有超过65个联合工作组参与，专注于定义和实现从工业现场设备（包括传感器/执行器）到企业和云系统的标准语境和语义数据模型。 OPC基金会与清洁能源和智能制造创新研究所（CESMII）共同开发的全球可用UA云库使OPC UA信息模型在全球范围内的云端可用，为用户提供查找和使用OPC模型的有效方法。这简化了为语义数据模型提供可信源的应用工程。

还有一个可扩展性与互操作性相结合的问题。物联网领域中的许多应用都利用MQTT作为一种轻量级方法向任意数量的信息使用方发布数据。然而，尽管MQTT支持可扩展性，但它本身并不能促进互操作性。另一方面，OPC基金会更理解集成的挑战不仅仅是对通信层加以规范，因此他们规范了从通信层到信息层的完整技术栈。而且OPC基金会更重视信息层，其主要价值主张都是通过信息层来展开的，OPC  UA专门用了4000多页来进行信息定义，而通信定义只有不到300页，就可见一斑。

Vol.4

MQTT/Sparkplug

也是一种解决方案

为了解决MQTT上缺乏信息互操作性的问题，Arcom/Eurotech于2015年创建了Sparkplug标准，以明确定义协议映射、编码方案、公共数据类型，以及自定义对象结构的方法。它最初是的一个不知名的专有定义，用于帮助通过MQTT进行内部集成。很快在一年之内，Cirrus Link使用该技术为美国Inductive Automation公司的Ignition（一个流行的SCADA/MES平台）开发了各种第三方模块。Ignition的MQTT引擎模块为数据存取互操作性建立了一个简单而明显的用例。

来自任意数量供应商的Sparkplug信息产生方将信息发布到标准MQTT代理。然后，这些信息立即可用，并在Ignition的内部标签结构中枚举为标签和用户定义类型（User Defined Types，UDT）。该功能最令人印象深刻的是，新连接的Sparkplug设备自动出现，无需终端用户或集成商输入。2019年，开源组织Eclipse基金会获得了Sparkplug规范的所有权。由于Ignition允许任何人通过免费和功能齐全的试用下载来评估其平台，包括任何业余爱好者都可以使用的免费Maker Edition，因此它的受欢迎程度持续增加。

Sparkplug从下往上构建堆栈，通过MQTT定义信息以实现互操作性，而OPC基金会则从上向下指定发布-订阅功能以实现可扩展性。OPC UA工作组开始开发标准，通过其他用例扩展其现有的信息定义，如防火墙遍历、控制器到控制器通信、控制器到云通信，或通过消息代理大规模连接信息产生方和信息使用方。之后，在2018年，OPC基金会发布了第14部分:Pub/Sub规范，MQTT已成为其四个通信协议中最受欢迎的，这主要是因为市场之前对树莓派应用、家庭自动化项目或其他物联网应用都用到MQTT，因而熟悉。此外，2021年5月发布的UA- IIoT - Starterkit仅支持MQTT，以至最近的OPC网络研讨会在提到Pub/Sub架构时主要讨论OPC UA over MQTT。图3给出Sparkplug与OPC UA over MQTT，看来OPC基金会正在工业物联网的范畴内仅支持MQTT，不支持其它的协议。

图3  Sparkplug和OPC UA over MQTT协议栈 （图源：IEB网站）

Vol.5

W3C正在开发物联网标准WoT

最近微软的工业物联网的总架构师向媒体透露，他们利用WoT的TD（Thing Description, ·物描述）作为架构模式，OPC UA作为接口，创建了一个参考实现，并以UA Edge Translator应用程序的形式演示这个概念。该应用程序运行在Docker容器中，便于部署在支持Docker或kubernetes的工业边缘网关上。通过扩展UA Cloud Publisher的UI，仅一次单击完成对UA Edge Translator的组态。目前，UA Edge Translator只处理Modbus设备，但添加其它设备也很方便。演示提供了SIEMENS SENTRON PAC电能表的WoT组态文件样本，其中已经包含了将电能表映射到标准化OPC UA PROFI能源配套规范所需的信息。OPC UA PROFI能源配套规范直接从UA云库加载。这一演示表明WoT开始步入工业物联网数据存取互操作性的战场。

万维网联盟（W3C）在交付全球公认的标准方面有着良好的记录，包括构建Web的HTML和CSS。在其麾下2020年成立了W3C物联网（WoT）工作组，其任务是通过构建模块的规范来对抗物联网的碎片化，从而实现跨物联网平台和应用领域的物联网设备和服务的轻松集成。作为现有标准的补充和增强，W3C WoT提供了标准化的元数据和其他可重用的技术构建块，目标是使跨物联网平台和应用领域的集成变得容易。其方法是通过遵循著名且成功的Web范式，通过提供一套标准化的技术构建模块，帮助简化物联网应用开发，增加灵活性和互操作性，特别是对于跨域的应用；同时支持已建立的标准和工具的重用。 通常，在现有的物联网项目中，开发人员必须面临以下挑战：必须了解来自不同供应商和制造商的不同物联网系统和服务组成的异构技术环境（参见图4）。这种多样性包括通信协议、有效负载数据交换的数据模型和安全需求的变化。物联网应用通常是针对一个狭窄而具体的用例开发，在其生命周期内，这些应用难以扩展、维护或重用。

WoT规范提供了一套标准化的技术构建模块，引入了一个基于属性、事件和动作的简单交互抽象。属性包括传感器的测量值（只读）、组态参数（读/写）、状态（只读或只写）、或计算结果（只读）、等等；动作包括机器启动/停止、淡入/淡出、长期持续的过程（打印文件、随时间改变属性等）、等等；事件包括现场报警、门已开、数据已在流动、等等。任何物联网网络接口都可以用这种抽象来描述（参见图5）。通过使用这种抽象，应用程序可以有一个通用的支撑（a common anchor）来检索物联网服务的元数据，了解可以访问哪些数据和物联网服务的功能，以及如何访问这些数据和服务的功能。物联网设备的元数据，包括实现这种通用抽象所需的所有信息，都被记录在所谓的WoT的 TD（物描述）中。TD是W3C物联网中的一个核心构建块，可以被视为物联网实例的入口端（很像网站的index.html）。它提供以下信息：相关的数据和功能，使用哪种协议，数据如何编码和结构化，使用安全机制控制存取，以及进一步的机器可读和人可读的元数据。TD用JSON-LD表示，可以由物联网设备本身提供，也可以托管在外部的存储库中，如TD目录。

图5  TD的概念图（图源：WoT网站）

总的来说，WoT是一个协议无关的方法，并提供了一个公共机制来定义如何将特定的协议（如MQTT、HTTP、CoAP或Modbus）映射到WoT的交互属性-动作-事件抽象中（参见图6）。这个映射和协议特定的元数据是由WoT绑定模板提供的。特定协议的绑定模板为客户端如何通过相应的面向网络的协议接口来激活每个WoT交互抽象提供了指导。

图6 由WoT物描述TD可推断出WoT脚本API （图源：WoT网站）

可选的WoT脚本API构建块定义了一个ECMAScript（JavaScript）API，它可由WoT物描述规范推断出来，并支持WoT交互抽象。它定义了行为实现和基于脚本的WoT运行时之间的接口。但是请注意，WoT的实现并不局限于脚本环境。Java或C/ c++中的编程语言API也可以从WoT的脚本API中派生出来。

Vol.6

适应工业物联网应用的

数据存取模型

其实从应用的角度看，工业系统需要实时、同步、协同的业务处理和制造过程，其重要基础就是全局的数据共享，而不是数据交换。这就要求有一个从数据存取架构的视角建立的数据存取模型，能够实现数据/信息的使用方与数据/信息的产生方解耦，就如在互联网中通过TCP/IP模型实现了数据/信息的存取与具体设备的地址脱钩那样。有人设想了这样的数据存取模型（见图7）。

图7 设想的数据存取模型 （图源：IEB网站）

要使数据/信息的使用方与数据/信息的产生方解耦，一个重要前提是实现点对基础架构的通信连接，而不是点对点的连接。在“点对点”体系结构中，信息使用方必须发起的连接数量与系统中信息产生方的数量直接相关。信息产生方的数量还规定了必须在信息使用方一侧设计的不同协议和客户自定义语法解析功能的数量。因此，随着信息产生方数量的增加和实现的协议数量的增加，点到点模型变得不可持续。 当从所有工厂设备收集信息时，企业系统受到了所需通信协议数量的挑战。对于应用程序来说，要做到跨所有设备且与任何协议通信，负担是在太大了。人们一直在努力通过将过多的通信协议通用化来消除这种负担，但一涉及到产品采用，那又是另外一回事了。工业自动化制造商不会只优先考虑标准化协议，而是继续在EtherCAT、PROFINET和EtherNet/IP等原生现场总线技术上进行创新。几乎所有的设备都继续支持Modbus/TCP来交换数据，有些还增加了IO-Link。一些设备已经发展到包含OPC UA服务器，但即使是OPC基金会成员的工业自动化制造商仍然省略OPC UA服务器。一些集成商和终端用户正在等待最新的设备规范OPC UA FX，期望它将导致更大的市场采用。相比之下，其他人严重怀疑在工业设备这一级别是否有可能采用标准协议。考虑到各种诉求和复杂情况，采用W3C的WoT解决方案是一个可行途径。

结束语      

时至今日我们尚不能看到适合全球的工业互联网和工业物联网的数据存取互操作性的明朗格局。我们盼望能在此方向加快进程，让企业在纳入新的数据/信息产生方或数据/信息使用方时不需花费或极少集成成本。    

编辑：黄飞