DDS-DCPS测试策略介绍及实际案例分析

DDS概述

根据上篇文章的介绍我们对DDS有了大致的了解，DDS中间件是一个软件层，它从操作系统、网络传输和低级数据格式的细节中抽象出应用程序。相同的概念和API以不同的编程语言提供，允许应用程序跨操作系统、语言和处理器架构交换信息。数据线格式、发现、连接、可靠性、协议、传输选择、QoS、安全等低级细节由中间件管理。那么这种相同的概念和API以不同的编程语言和不同的供应商来实现的中间件软件集成到不同的控制器中协同工作，就一定可以进行互操作吗？答案肯定是不一定的，这就需要我们对DCPS层进行接口测试，保证软件符合DDS协议执行标准。

DCPS层接口测试

DCPS，全称Data-Centric Publish-Subscribe（以数据为中心的发布-订阅），DCPS定义了应用程序用来发布和订阅数据对象值的功能。

测试解决方案

为了保证来自不同供应商的DDS软件功能的正确性以及互操作性，我们需要对其进行DCPS层的协议一致性测试。针对于DCPS层的接口测试我们东信创智开发出了DDS_UT。

DDS_UT是DDS的一个应用程序，利用交叉编译将DDS_UT集成到控制器内部，即可调用DDS中间件的接口函数，再将控制器通过VN系列盒子连接到PC端。利用CANoe端与DDS_UT交互输入不同的入参判断API执行结果是否为期待的返回值来进行DCPS层的接口测试。DDS_UT类似于TC8测试中UpperTester的功能。

图1 测试环境

实际案例分析

对于DCPS层的接口测试，我们开发出400余条测试用例，分别有DataWriter测试、DataReader测试、DomainParticipantFactory测试、DomainParticipant测试、Publisher测试、Topic测试、TypeSupport测试、Subscribe测试。

图2 测试用例列表

执行TG1_TC1用例，测试当LIVELINESS 设置为MANUAL_BY_PARTICIPANT或MANUAL_BY_TOPIC通过调用assert_liveliness手动判断在设定时间内DataWriter是否活跃。

图3 测试规范

通过CANoe的Test Module勾选需要执行的测试用例。

图4 测试界面

在CANoe端利用CAPL脚本对DDS_UT发送指令，DDS_UT接收到指令后执行相应的函数操作，并将执行结果发送回CANoe端，CAPL脚本根据规范判断其结果是否通过，在Write窗口可以看到运行日志。

图5 CANoe端write窗口页面

测试结果生成HTML测试报告。

图6 测试结果

这条用例中assert_liveliness操作用于手动判断DataWriter的活动性。这与LIVELINESS Qos策略结合使用，以指示服务实体保持活动状态。只有当LIVELINESS设置为“MANUAL_BY_PARTICIPANT”或“MANUAL_BY_TOPIC”时，才需要执行assert_liveliness。否则它没有任何作用。此条用例中kind设置为“MANUAL_BY_PARTICIPANT”且执行assert_liveliness成功，因此TG1_TC1执行结果为PASS。

结语

DCPS层接口测试对于确保不同DDS实现之间的互操作性至关重要，四百余条测试用例也基本可以将DCPS层覆盖全面,但是DDS的标准中不包含传输层协议，为了更进一步实现不同软件之间的互操作性，RTPS传输协议由此诞生，所以针对于RTPS的协议一致性测试也是重中之重，RTPS的测试方案我们将在下一次的介绍中详细展开，请大家持续关注。