根据上篇文章《DDS数据分发服务—提升汽车领域数据传输效率》的介绍，我们对DDS有了大致的了解。DDS中间件是一个软件层，它从操作系统、网络传输和低级数据格式的细节中抽象出应用程序。相同的概念和API以不同的编程语言提供，允许应用程序跨操作系统、语言和处理器架构交换信息。数据线格式、发现、连接、可靠性、协议、传输选择、QoS、安全等低级细节由中间件管理。那么这种相同的概念和API以不同的编程语言和不同的供应商来实现的中间件软件集成到不同的控制器中协同工作，就一定可以进行互操作吗？答案肯定是不一定的，这就需要我们对DCPS层进行接口测试，保证软件符合DDS协议执行标准。
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的测试方案我们将在下一次的介绍中详细展开，请大家持续关注。
东信创智一直深耕于电子电气架构开发、车载总线通信与诊断测试、整车控制系统XIL仿真测试平台、控制系统及整车功能测试服务、嵌入式软件开发与集成服务等多个领域，致力于为客户提供安全可靠的研发工具和“本地化、快速化、定制化、产品化”的解决方案。东信创智不但在汽车电子传统领域的经验和能力一直处于行业前列，如CAN/LIN/Ethernet开发与测试、控制系统功能测试、整车功能验证测试、控制系统HIL仿真平台、AUTOSAR软件开发与服务等，而且在新兴技术的探索方面持续不断的提前投入研发，如ADAS智驾仿真、HMI测试验证、SOA架构开发、V2X测试验证、OTA测试验证、信息安全与功能安全等，均取得了可喜的成果。东信创智拥有多支“敢于挑战、乐于进取、善于拼搏、忠于客户”的经验丰富的技术服务团队，同众多合作伙伴一道整合全球优质资源，为客户提供“高效、高质、高价值”的产品与服务。
