OPC UA性能评估

本文是对这篇论文的总结，该文章从性能和资源使用方面比较了工业4.0的4个主要协议：OPC UA，DDS，ROS和MQTT。

这4个协议都是基于以太网（Ethernet-based），随着以太网实时特性的不断优化，在未来发展中，基于以太网的协议正在逐步代替传统且专有的现场总线协议。

PS：论文作者也是open62541的创建者（open62541是OPC UA的一个开源实现）。

一协议简介

1）OPC UA

全称是Open Platform Communications Unified Architecture，是一个面向服务的machine-to-machine的通信协议，主要用于工业自动化。在IEC 62541协议里定义。

主要目标是为了提供一种跨平台且使用信息模型来描述传输数据的通信协议。其最强大之处，如下介绍，

The major strength of OPC UA is the semantic description of the address space model together with various companion specifications which extend the basic semantic descriptions for various domains like PLCopen, robotics, or computer vision.

简单理解就是这个协议在地址空间里不但提供了基础语义描述，同时提供了各种行业规范的语义描述，如PLCopen，Robotics，计算机视觉等。用户不仅可以自定义各种语义描述，同时也可以直接使用现成的，都非常方便。

另外，OPC UA前些年还发布了Publish/Subscribe协议，可以让用户使用发布订阅功能。

PS：这里简单讲下什么是语义，英文叫semantic，打个比喻，假如你要表示一个意思 — 我要去吃饭，那么你面对一个中国人就会用汉语说“我要去吃饭”，如果你面对一个英国人，你会说：I’m going to have dinner，要去吃饭就是语义，用汉语和英语表达这个意思就是语法。

2）DDS

全称是Data Distribution Service，是以数据为中心的Publish/Subscribe中间件，用于高动态分布式系统。由Object Management Group (OMG)标准化。

OPCUA是以设备为中心，相比OPCUA，DDS则更专注于数据：数据发布到DDS的域里，然后订阅者可以从DDS域里订阅这些数据，不用关心这些数据来自哪里以及如何排布的，因为在信息包里已经描述好了。

DDS主要用在铁路网络，空中交通管制，医疗，军事，太空以及工业自动化。

3）ROS

全称是Robot Operating System，是一个开源软件框架，主要用于工业机器人，最初由Willow Garage开发，由Open Source Robotics Foundation (OSRF)提供支持，并且有一个很大的社区。

ROS的继任者是ROS2，ROS使用专有数据格式，而ROS2则是建立在DDS基础之上。本文只讨论ROS

4）MQTT

全称是Message Queuing Telemetry Transport，是一个非常轻量的Publish/Subscribe物联网协议。用于低速率，且网络环境比较差的情况。在2013年，由Organization for the Advancement of Structured Information
Standards (OASIS) 标准化。

MQTT协议需要一个MQTT服务器，也就是broker，有了服务器之后，client只需要把数据发布到server上就可以了，自己本地不需要再保存了。

5）小结

下面是对以上4种协议的小结：

OPC UA以设备为中心，强调设备之间的交互，而这些设备可能运行在不同的系统里
DDS则是专注于集成在单个系统中的软件
ROS专注于硬件抽象，不同研究小组的协作和软件组件的重用
MQTT专注于硬件性能低下的远程设备以及网络状况糟糕的情况，这也是为什么MQTT不提供很多其它特性，如RPC和Discovery等

可以看出OPC UA更适合在制造工厂里使用：工厂里的生产线基本都是由不同的系统构建而成，而这些系统则是运行在不同设备上的。

二特性比较

这4种协议的特性比较如下，

解析如下：

Communication：4种协议都可以使用TCP进行通信，差异是：MQTT只支持TCP，不支持UDP；DDS除了TCP和UDP之外，还支持Share memory，这样多个DDS节点可以通过共享内存进行互相通信；OPC UA和ROS也都支持UDP
Pattern：4种协议都支持Pub/Sub模式，OPC UA和ROS原生支持RPC（Remote Procedure Calls，远程过程调用），DDS标准化了RPC但是具体实现中基本都没实现。MQTT不支持RPC
Authentication：OPC UA和MQTT支持用户名密码或PKI（private key
infrastructure）方式的身份认证功能；DDS只支持PKI方式的身份认证；ROS只支持使用MAC地址的身份认证，而且是通过第三方软件包来实现。
Encryption：只有ROS不支持应用层加密，其它三个协议都支持加密。
Std. API：只有DDS定义了标准用户API，理论上来说不同的DDS实现之间可以互相交换而不用修改源码（因为API相同），但是实际很难做到这点，因为不同的DDS实现基本都添加了自定义的方法来配置运行栈。
Semantic Data：只有OPC UA 提供支持，该协议使用地址模型来向client提供数据，地址模型包含数据的语义注解，这样client可以自动推断出数据值的实际意义。ROS，DDS和MQTT都是把数据值发布到指定的topic上，这就意味着client需要事先知道topic的名称才能拿到需要的数据。另外，OPC UA中有多种reference类型，可用于连接节点，这个和三重存储的数据库类似。

三通信的数据包开销(Package Overhead)

论文中用来进行测试的中间件如下，

OPC UA： open62541，License MPL2.0，Version 0.3-rc2
ROS：ROS C++，License BSD，Version Kinetic Kame
DDS：eProsima Fast RTPS，License Apache 2, Version 1.6.0
MQTT：Eclipse Paho MQTT C，License EPL1.0. Version 1.2.1

首先，从理论上来比较一下4种协议在传输数据包时的开销。在传输一笔数据(payload)时，每一种协议都会添加一些包头（package header），用来告诉接收方这个数据是什么。包头会额外增加开销，这样就可能让传输无法达到最大带宽。

论文比较了当payload是0, 10, 100, 1000, 10000字节时，实际传输的数据大小（加上了协议要求的包头），如下表，

PS：最后一列是协议对应的client和server建立连接时需要的数据量，其中没有读写请求。

表中记录的数据量是从中间件层(OSI layer 5, Session)传到TCP/UDP层 (OSI layer 4)时的数据量，另外需要注意的是，表中数据值不包含TCP/UDP自身的header大小。

可以看出当OPC UA的包头最大，MQTT的包头最小，但是当payload很大时包头的影响就变小了。

下面分析表中最后一列，即建立连接时需要的数据量：

1. OPC UA

测试方式是让client向server发送一个变量写请求(基于TCP)，不使用加密（加密又会增加一些开销）。具体操作过程如下，

Client打开一个安全通道(OpenSecureChannelRequest, 132 bytes)
获取可用的endpoints (GetEndpointsRequest, 93 bytes)
创建会话(CreateSession Request, 138 bytes, depending on the hostname, here localhost:4840)
激活会话 (Activate SessionRequest, 137 bytes, depending on the identity token length, here open62541-anonymous-policy)，必须在发送写请求之前激活
关闭会话 (CloseSessionRequest, 75 bytes)
关闭安全通道 (CloseSecureChannelRequest, 57 bytes)

可以看出，处理连接(不包含发送写请求)总共需要的数据量为：132 + 93 + 138 + 137 + 75 + 57 = 632 bytes.

2. MQTT

连接到MQTT broker的payload大小取决于发布者的名字长度，在测试中把发布者的名字设置为1个字节，连接成功需要15个字节，断开连接需要2个字节。处理连接总共需要15+2=17 bytes。

另外，发布消息的大小同时也取决于topic的名字长度，同样设置为1个字节。

3. ROS

首先要了解一下ROS的工作过程：

在一台机器上先开启ROS core，每个ROS节点启动时都需要ROS core的IP地址
在启动阶段，ROS节点都会向ROS core发送XMLRPC请求来交换这些信息：当前系统状态，节点topics的所有发布者和订阅者
当2个节点有一对匹配的发布者/订阅者，那么这2个节点就会通过独立的TCP连接进行连接，并使用TCPROS协议用于订阅
当断开连接时，ROS节点会通过XMLRPC9从core里注销自己

在测试中，节点发送的XMLRPC请求(连接core并与core交换信息)需要的payload大小是 5693 bytes；断开连接需要 3046 bytes。这样算下来需要 5693 + 3046 = 8739 bytes，这还不包含节点间交换TCPROS信息的payload大小。节点间建立联系后，在独立的TCPROS通道上，订阅者节点连接到发布者节点（这需要一些额外的信息），发布者节点会返回它自己的发布信息（176字节）用于建立连接。

那么最终处理连接需要的TCP payload字节总数是8739 + 176 = 8915 bytes

4. DDS

DDS的节点搜索流程(discovery process)取决于具体的实现栈。在本论文测试中，使用的是eProsima Fast RTPS，该实现会分2步去发现网络中的其它节点：

在participant discovery阶段，节点会发送多播消息去发现其它参与者，并周期性的发送心跳包。当2个节点互相发现对方后，就会交换这些信息：information about published and provided topics with
the other endpoint in the endpoint discovery phase
在endpoint discovery阶段，发布者和订阅者需要告知另外一端，只有这样才能互相交换信息。

在测试过程中，server总共发送了8348个字节用于设置连接，这些数据封装在RTPS (Real-Time Publish Subscribe)包里并作为UDP payload发送出去。

5. 小结

通过以上测试评估可以看出，MQTT不仅在连接初始化过程中需要最少的数据量，而且在发送数据时也只需要最少的开销。OPC UA C/S在连接初始化排名中排第二，在发送数据的开销排名中排最后一名。ROS在设置连接中需要最多的数据量，这是因为它使用XMLRPC，这个会给ROS core发送无压缩的XML文本，但是其payload的开销却是很低的。DDS的payload开销相比OPC UA小一点点，在设置连接中需要的字节数比ROS小一点点。

可以看出，所有的协议开销基本上都是常数（去掉实际的payload），只有MQTT是例外，它的包头里用于表示数据长度的域会根据payload大小进行变化（1~4字节）。

MQTT和ROS相比于OPC UA和DDS有个比较大的区别：MQTT和ROS在一对发布者订阅者之间会创建一个专门的TCP连接，传输的数据类型是固定的，也是双方都知道的，不需要额外的信息来解释数据是干啥的；在OPC UA和DDS里，连接通道中可以传输各种各样的数据，这就需要在payload里添加额外的identification data。

DDS和OPC UA可以给传输的数据包添加额外的诊断信息；而对于轻量级协议(ROS, MQTT)，这个诊断数据需要单独的搜集。

四测试准备和规划

测试环境由两台电脑组成：

一台Linux客户机
一台Linux服务器作为远程主机

客户机和服务器通过千兆网络交换机(TP-Link TLSG1024DE)进行连接，这两台机器配置相同：i7-8700K CPU with 3.70 GHz，64 GB内存，Ubuntu 16.04.4 with Preempt-RT Kernel 4.14.59-rt37 (Preempt-RT表示内核是实时内核，可以保证测试的高性能和reproducibility )
经过测试，这两台机器之间的平均往返时延(round-trip time, RTT)是0.35ms，网络带宽最高可达724 Mbit/s

测试规划：server提供方法，client调用server提供的方法并测量服务器的性能。对于MQTT，DDS和OPC UA Pub/Sub，使用2个topic来实现：一个topic用于发送数据，另外一个topic用于接收response。所有的测试必须都可以使用一条命令重复进行，同时会把时间值保存到文件里。

为了比较测试时的性能和系统负载，使用以下几个衡量标准：

CPU usage,
RAM usage
messages per second
round-trip time (RTT)

使用2种模式进行测试：acknowledge(ACK)模式和echo模式。在ACK模式中，client发送一个请求然后等待server返回一个简单的应答(1个字节)，这个模式可以用来测试单条消息的相应时间。在echo模式下，client发给server任意数据，server就会回复相同的数据字节，这个模式可以测量中间件的吞吐量。这2种模式的请求交替发送，即ACK模式的请求发送完马上发送echo模式的请求，请求之间不等待，总共发送5000个请求。下一步把请求中的payload加倍，然后再发送5000次(ACK和echo交替)，payload大小从2字节一直到32768字节，每一种payload大小都发送5000次。

对于RTT，测试这样做：在30秒内，client先随机等待一段时间(0~3秒)，然后使用ACK模式发送请求，并测量RTT。

为了测试中间件在非理想环境下的性能，使用第三方工具来产生大量的network traffic和CPU usage：使用Ostinato负载生成器产生网络负载，使用stress工具产生CPU负载。

以上这些会产生7种测试：

系统处于idle状态下的ACK测试
系统处于idle状态下的echo测试
系统网络负载很大时的ACK测试
系统网络负载很大时的echo测试
系统CPU负载很大时的ACK测试
系统CPU负载很大时的echo测试
RTT测试

还有最后一个测试：在server上同时运行500个同种中间件实例，分成10组，每组50个实例，客户端会连接每组中的第一个实例，这样就会同时连接10个实例，然后同时给每个实例发送一个包含10240字节的数据包，实例收到数据包之后再把数据包转发给下一个实例，这样会重复转发50次，在server端就会有10个发送流并行运行。最后一个实例会把数据包返还给client，以此来测试这10个数据包的完整RTT。整个测试过程重复100次来获取平均结果。这个测试可以展示出是否允许用户同时开启多个实例。

五性能评价

需要注意一点：本次测试中每一种协议都是用最常用的C/C++开源实现，但是不能认为这代表了协议的其它实现，因为不同实现的性能可能是不一样的，另外，RTT越小越好。

下面是本次测试中得到的图表：

图片1a~1c，1e和1g展示了4种协议的RTT箱形图，其具体数值则是在Table III里。

注意：CPU load表示CPU负载达到100%时进行的测试，Net Load表示网络负载达到100%时进行的测试。

OPC UA和ROS的RTT与服务器的CPU load大小无关，其RTT和idle状态下的RTT基本一样。MQTT和DDS在CPU load下的RTT与idle下的RTT相比，则是显著下降了~300us

而Net Load下的测试显示，使用了TCP的协议(OPC UA Client/Server, MQTT)受到影响比使用UDP的协议(OPC UA Pub/Sub, DDS, ROS)要小一点，但是所有的协议都下降超过400us

图片1d和1f是组合视图，把所有的协议放一起比较，同时包含了一个简单的Raw TCP和Raw UDP的echo/ACK模式测试(使用C做的)。可以看出Raw UDP在交换小数据量时是最快的，接着是Raw TCP，在交换大数据量时拥有更好的性能。除了Raw TCP和Raw UDP之外，open62541 OPC UA Pub/Sub是最快的，然后是open62541 OPC UA Client/Server，ROS和MQTT。另外，MQTT数据中包含最多的逸出值(应该是表示稳定性最差)。

通过测试发现中间件中对RTT的影响最大的操作：从socket中读取数据然后转发给用户代码。因为这个步骤中需要分配内存，而内存分配是开销比较大的操作。eProsima Fast RTPS和open62541 OPC UA会传递const的数据指针给用户代码，而MQTT和ROS则是使用拷贝操作。

图片1h展示的是顺序请求的RTT，即client随机等待一段时间(0~3s)，然后发送包含4字节的单个请求并等待应答，重复测试100次。可以看出DDS是最慢的，对于OPC UA，MQTT和ROS，测量值和图片1d差不多。

最后一个测试是在服务器上运行500个相同中间件的实例，然后执行转发数据等操作，上一节已经介绍了。测试显示open62541 OPC UA Client/Server是最快的。而MQTT和ROS则是最慢的，而且是非常慢，根本原因是OPC UA使用直接的TCP连接，而MQTT使用stateless UDP连接，ROS则是被它自己产生的高CPU负载所拖累。

六结论

OPC UA在信息的语义建模上有突出优势。ROS主要用于机器人，并且有很多功能包。DDS有一个QOS的扩展集，而MQTT主要用于轻量级的publish/subscribe操作。

性能比较显示：open62541 for OPC UA和eProsima FastRTPS for DDS拥有比较高的性能，而MQTT和ROS的实现在RTT上表现很差。

最后，这篇论文的连接是https://mediatum.ub.tum.de/doc/1470362/096544428163.pdf，可以直接去阅读。