DDS—RTPS一致性测试案例分析

Dotrust东信创智

于 2024-12-13 14:16:22 发布

阅读量1.1k

点赞数 20

文章标签：网络

本文链接：https://blog.youkuaiyun.com/Dotrust2013/article/details/144448806

版权

1 往期回顾

通过《DDS数据分发服务—提升汽车领域数据传输效率》和《DDS—DCPS测试策略介绍及实际案例分析》这两篇文章的介绍，相信广大读者对Data Distribution Service(DDS)协议和Data Centric Publish Subscribe(DCPS)测试有了基本了解：DDS协议致力于实现功能开发和通信解耦，使开发人员更专注处理获取信息，而不必维护频繁更新的通信节点；DCPS测试则是为了保证不同供应商协议栈的API接口行为符合DDS协议规定，简化应用层代码的移植难度。而今天的主题则是The Real-time Publish-Subscribe Protocol DDS Interoperability Wire Protocol Specification(RTPS)的一致性测试，将通过一个测试用例来带领大家了解RTPS的报文识别、通信流程和测试过程。

2 RTPS一致性测试

RTPS一致性测试主要测试不同供应商开发的DDS协议栈能否按RTPS协议规定的方式进行通信，保证其具有互操作性。那么说到测试，首先就要介绍一下测试环境，如图1所示：

图1 开发环境示意

这个环境中，CANoe作为测试节点和以太网网关节点，负责控制测试流程、报告生成以及错误注入等功能。在Ubuntu中的DDS UT作为Tester，控制器/Ubuntu作为Device Under Test‌(DUT)，两者根据CANoe的指令相互协作，完成测试流程。

2.1测试用例简介

测试目标

验证DUT作为可靠的Reader时，当通信过程中发生数据丢失，其请求重新发送数据的操作是否正确。

测试步骤

DUT创建可靠的RTPS Reader；
Tester创建可靠的RTPS Writer，Topic与DUT相同；
启动Tester和DUT，待其建立连接后，Tester向DUT发送5个DATA消息，其中（seq_num = 3）的DATA消息丢失；
期待DUT发送ACKNACK请求重传seq_num = 3的DATA消息；
检查并记录DUT收到的消息。

通过条件

Tester收到DUT发送的ACKNACK请求重传seq_num = 3的DATA子消息；
DUT收到所有（seq_num = 1 - 5）DATA子消息；

测试环境为图1所示，其中Tester的IP = 192.168.200.110，和CANoe部署在同一台电脑上，DUT的IP = 192.168.100.60，部署在另一台电脑上，两者通过VN5650交互通信报文，而CANoe负责给Tester和DUT下发指令、转发报文、生成测试报告以及错误注入。

2.2测试执行

测试环境按图1部署好后，运行CANoe脚本开始测试，整体测试结果如图2所示：

图2 测试结果展示

图2a是CANoe的以太网Trace窗口截图。图2b是CANoe的测试用例截图，采用xml测试节点，选中指定测试用例执行即可。

图2c和图2d分别是Tester和DUT的执行结果截图，图中展示了测试开始时，两端的DUT分别接收了CANoe发送的测试指令，包括执行发送数据的间隔、数据个数、数据长度和服务质量（Quality of Service (QoS)）等。Tester在测试中扮演Writer，发送5条DATA，数据长度为10byte，间隔1000ms并指定QoS的RELIABILITY = RELIABLE、DURABILITY = PERSISTENT； DUT为Reader，QoS与Writer相同，测试过程中分别在终端打印了发送和接收的数据，同时DDS UT还会将发送和接收的数据分别发送给CANoe，这些数据用来判断测试结果，最后测试执行完成后分别释放了Writer和Reader。

2.3 报文分析

这里采用Wireshark为大家展示测试过程中的RTPS报文，该测试用例的整个报文交互如图3所示:

图3 测试全过程的报文交互流程

图中的INFO_DST、HEARTBEAT、ACKNACK等子消息是非常好理解的，指的就是RTPS协议所规定的子消息，但是对于DATA消息大家可能会比较疑惑，为什么会有这么多DATA子消息？DATA(p)、DATA(r) 、DATA(w) 、DATA(m)、DATA、DATA(r[UD])、DATA(w[UD]) 、DATA(p[UD])都是什么作用？Wireshark是如何识别并标记这些子消息的？

网上介绍这方面的资料很少，因此小编在这个方面还是遇到一些坎坷，所以先简单介绍下如何解读Wireshark的RTPS报文以及Writer和Reader的交互流程，希望可以给读者一些启示。以下是小编对协议的个人理解，难免有误，欢迎大家在评论区交流，共同进步。

对于以上问题首先要回到RTPS协议本身，在RTPS[1]协议的9.3.1.3 Predefined EntityIds章节规定了一些entity，表1节选了部分Entity。

Entity	Corresponding value for entityId_t (NAME = value)
SPDPbuiltinParticipantWriter	ENTITYID_SPDP_BUILTIN_PARTICIPANT_ANNOUNCER = {{00,01,00},c2}
SPDPbuiltinParticipantReader	ENTITYID_SPDP_BUILTIN_PARTICIPANT_DETECTOR = {{00,01,00},c7}
SEDPbuiltinPublicationsWriter	ENTITYID_SEDP_BUILTIN_PUBLICATIONS_ANNOUNCER = {{00,00,03},c2}
SEDPbuiltinPublicationsReader	ENTITYID_SEDP_BUILTIN_PUBLICATIONS_DETECTOR = {{00,00,03},c7}
SEDPbuiltinSubscriptionsWriter	ENTITYID_SEDP_BUILTIN_SUBSCRIPTIONS_ANNOUNCER = {{00,00,04},c2}
SEDPbuiltinSubscriptionsReader	ENTITYID_SEDP_BUILTIN_SUBSCRIPTIONS_DETECTOR = {{00,00,04},c7}
BuiltinParticipantMessageWriter	ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_WRITER ={{00,02,00},c2}
BuiltinParticipantMessageReader	ENTITYID_P2P_BUILTIN_PARTICIPANT_MESSAGE_READER = {{00,02,00},c7}

表1 EntityId_t values fully predefined by the RTPS Protocol

其实这些Predefined Entity（由上至下）发送的DATA就分别对应Wireshark报文中的DATA(p) 、DATA(w) 、DATA(r)和DATA(m)， DATA(*[UD])指的是这些Entity释放时的通知消息，而DATA指的是由User-defined Entity发送的消息，下面分别介绍下这些DATA的作用。

DATA(p)主要实现协议规定的Simple Participant Discovery Protocol(SPDP)发现流程，负责广播自身的单播、多播IP地址和端口号等信息，Entity发现后就进入Simple Endpoint Discovery Protocol(SEDP)流程。

DATA(w)由Writer的SEDPbuiltinPublications Entity发出，实现SEDP发现流程，向Reader公布自身的QoS、Topic等关键信息，同理DATA(r)由Reader的SEDPbuiltinSubscriptions Entity发出，向Writer公布自身的QoS、Topic等关键信息，如果两者Topic相同并且QoS兼容，则可以互相发现并通信。

DATA(m)由BuiltinParticipantMessage Entity发出，声明自身的活性并公布LIVELINESS QoS的LivelinessQosPolicyKind（用于声明存活性的管理归属），如图4所示：

图4 DATA(m)细节

图中的LivelinessQosPolicyKind = 0x0001，表示DDS 会自动管理存活状态，无需在应用程序中显式地声明（指主动调用assert_liveliness()）其存活状态。

DATA指的是由User-defined Entity发送的消息，Writer向Reader发送Topic的应用数据。

DATA(*[UD])指的是这些Entity释放时的通知消息，判断的依据是其inlineQos的flags标志位是否将Unregistered和Disposed置1，如图5所示：

图5 DATA(r[UD])细节

当我们知道了这些DATA的含义，也就知道了典型的RTPS实体是如何相互发现并进行信息交互，主要流程如下：

- 成功创建Writer或Reader后进入SPDP阶段，分别通过广播的DATA(p)公布自身的Ip和端口号等信息；
- 互相发现后进入SEDP阶段，通过DATA(w)和DATA(r)交换彼此的QoS和Topic等信息；
- 匹配后，Wrtier通过DATA向Reader发送Topic的应用数据。如果是可靠通信，则Reader必须发送ACKNACK进行确认，当报文丢失则通过ACKNACK通知丢失报文的序号，Writer会重传丢失的报文，同时在约定的时间内通过DATA(m)互相声明存活性；
- 当一方程序退出时，发送DATA(*[UD])通知对端自身下线了，然后结束通信流程。

再回到这个测试用例，当知道了DATA报文的“隐藏”含义，我们也能通过报文分析整个测试流程。由图3可知：当Writer和Reader相互发现并匹配后，Writer向Reader发送总计5条DATA消息（仔细观察可以发现图中共有6个DATA），其中重传了seq_num = 3的DATA子消息，当发送完第五个子消息后，Writer和Reader分别下线并结束测试。

2.4 测试结果

测试完成后，CANoe会自动生成测试报告，通过报告能更加直观地查看测试过程。我们的脚本实现了全部子消息的报文解析，为了方便测试人员清晰的看出测试要点和测试步骤，这条测试用例选择性的解析了DATA和ACKNACK，如图6所示：

图6 CANoe测试报告

CANoe作为网关对通信报文进行转发和错误注入，测试过程中转发普通的RTPS报文，同时只拦截了第一个seq_num = 3的DATA子消息（时间戳5.538000），模拟了通信过程中报文丢失的情况。当DUT发现seq_num = 3的DATA子消息丢失后，立刻发送ACKNACK（时间戳5.642000）消息进行重传，Tester收到后立刻重传了“丢失的”DATA消息（时间戳5.644609）。当DUT收到DATA消息后，向CANoe发送了接收到的消息序列（时间戳5.644609），脚本会验证接收到的是否和发送的（时间戳5.537761，发送消息时Tester也会把消息序列发送给脚本）一致，如果一致则该测试用例pass，否则fail。