软件定义汽车对测试的影响

OEM和供应商之间传统的合作模式是由OEM释放技术需求，供应商按照需求进行软件和硬件实现，最终交付的是完整的软硬件系统。随着集中式架构的逐步演进，这种合作模式正在被打破——标准化的高性能硬件平台、高级操作系统、中间件以及虚拟化技术得以应用，使硬件越来越抽象化，可以使应用程序脱离硬件，相对独立的进行开发和测试。这就允许ECU的开发可以进行更细致的分工，比如硬件由供应商A提供，操作系统和基础软件由供应商B进行开发或集成，应用软件由供应商C开发等等。可以说OEM和供应商的合作模式更灵活了。

OEM作为集成方，需要对来自不同供应商的模块进行“验收测试”，其目的是确认该模块是否按照需求进行实现。根据需求类型可以将验收测试划分为三个部分：针对行业标准的验收测试，针对OEM企业标准的验收测试，以及针对车型项目需求的验收测试。其中每个部分又根据测试方法的不同而分成两种类型，分别是静态审查和动态测试。

OEM和供应商的合作模式的改变对其中动态测试的部分的影响很大。进行动态测试时，测试环境需要为被测对象提供运行环境，并且能够仿真系统中的其他部分（或称残余系统）与被测对象的交互。在传统的OEM和供应商的合作模式下，供应商交付的是ECU实体，是包含软件和硬件的一整套系统，所以这时候所谓的动态测试指的就是ECU的HiL测试。这种情况下ECU和残余系统的交互实现方案相对来说是标准化的，如CAN/LIN等总线信号以及I/O信号，目前有非常成熟的解决方案。而当OEM和供应商的合作模式改变之后，供应商交付物的形态更加多样，它可能是一个完整的ECU，或者一个操作系统，或者一个中间件，或者一个应用软件。这种多样性对动态测试环境的搭建带来了挑战，比如把应用程序作为被测对象，我们需要模拟被测对象依赖的全部环境，包括操作系统、依赖库和硬件等，十分困难。因为测试方案不像原来一样标准化了，测试系统很难像流水线一样生产出来。新的模式下，我们需要和每一个客户深入沟通，明确测试对象是什么，边界在哪里，需求是什么，然后才能进一步评估，制定合适的测试方案。

DDS中间件的测试策略

DDS中间件即是上述新模式下的一个典型例子，那么如何对这种产品进行测试呢？

对于成熟的标准的软件产品，比如Linux，QNX等，我们其实并不需要对其核心功能进行太多测试，因为软件厂商或开发者会在产品开发过程中进行大量测试，市场和时间也能充分证明其质量的可靠性，这也是我们选择成熟软件模块的意义所在。然而，当我们把来自不同供应商的标准产品放到同一个系统或网络中协同工作时，必须考虑到它们之间是否兼容，也就是互操作问题。

那么对DDS来说，会出现互操作问题吗？这需要分情况讨论。

如果参与DDS通信的节点均是基于高性能SoC实现，并且运行标准操作系统（如Linux，QNX等），得益于DDS良好的可移植性和OS无关的特性，OEM可以采用成熟的商业产品或开源产品，然后部署在每个节点中。此时，若所有节点运行着相同的来源和版本的DDS中间件，显然这种模式下我们可以忽略互操作的问题。

然而，目前也有不少厂商正在尝试或已经实现向MCU中集成DDS中间件。受限于MCU性能和资源，DDS软件必须经过适当裁剪和优化才能在MCU的环境下运行。同时，MCU软硬件高度耦合，软件移植、复用和维护并不容易，这种情况下我们可能不能再将其视为成熟的软件模块，厂商因此需要对DDS软件进行大量的测试来保证DDS系统的质量。这种情况下，为了避免与其他DDS软件互通时产生交互问题，互操作测试是必不可少的。除了上述情况，如果DDS中间件来源或版本存在差别，互操作性测试也将是十分必要的。

除了互操作测试，另一个更重要的关注点是系统测试，具体来说是DDS中间件集成至目标平台后，会不会出现系统性问题。因为车载电子电器系统的计算平台五花八门，不同车型平台，不同项目，其搭载的系统平台（包括芯片架构，操作系统等）可能都有不同，甚至还有像基于MCU的DDS这种嵌入式软件，这些不同的平台相互的组合情况，DDS QoS配置组合情况，以及复杂的网络配置情况（如DDS-TSN），更难以计数。尽管DDS协议栈厂商可能会验证DDS产品与常见平台的兼容性，但是这很难覆盖所有可能的系统配置。所以我们认为在上述情况下对DDS中间件进行功能和性能测试是有必要的。

DDS协议测试工具介绍

基于上文对测试策略的讨论和实践总结，北汇信息与南京臻融软件科技合作开发了DDS协议测试套件，该产品能够在特定系统环境下验证DDS中间件的功能和性能，以及不同的DDS产品之间的互操作性。

南京臻融软件科技有限公司多年来专注于DDS产品与相关工具链的自主研发。其产品ZRDDS是我国首个100%自主研制并被OMG组织官方认证的DDS产品。 

图1：DDS协议测试的测试框架示意

图1显示了DDS协议测试的测试框架示意。上位机中运行的DDS Test Frame软件能够提供图形化的用户界面，具备测试用例管理，测试用例执行监控，测试报告生成，测试系统配置等功能。DDS Tester是专门为测试而开发的应用程序，在开始测试之前需要将此应用植入被测系统的每个节点内部。测试执行过程中，上位机将指令下发至DDS Tester，DDS Tester按照指令内容执行操作，比如调用某个应用程序接口，并将结果返回至上位机。其角色类似于TC8 TCP/IP测试中的Upper Tester。得益于DDS标准化的应用程序接口，理论上DDS Tester可在不同供应商的DDS产品之间轻松移植。

当然，DDS节点并不一定只通过以太网进行通信，其他还包括板载交换机的介质无关接口，共享内存，或者本地环回网络等等，测试环境可以根据系统的实际情况进行搭建。

DDS协议测试规范/用例完全自主设计开发，并且在多年的项目实践中不断进行迭代和优化，目前可以覆盖OMG DDS 1.4所定义的DCPS的核心功能，包括DDS应用程序接口的行为，QoS行为，以及性能测试，共计400余条测试用例，通过所开发的测试脚本套件，全部可实现自动化执行。

DDS协议测试实践

如下示例展示了DDS测试的执行过程。

图2：测试环境

图3：DDS Tester 运行界面

测试环境如图2所示，为便于展示，被测系统为Windows主机中运行的两台Ubuntu虚拟机，两台虚拟机中均运行DDS Tester。被测DDS为某DDS中间件产品，目前在汽车行业内已经得到较广应用。

在上位机软件DDS Test Frame中选择并执行测试用例，如图4所示。

图4：在DDS Test Frame中执行测试用例

我们以DisposeWTimeStamp_WrongHandle这条失败的测试用例来说明一下测试问题的分析步骤。测试步骤如下表所示。

在这条测试用例中，DDS Test Frame发送指令，使DDS Tester创建同一个Topic的两个数据，分别为Data1和Data2，Topic中指定“key”为键，不同键值的两个数据应视为同一个Topic的两个不同的实例。之后创建对应的DDS实体，包括DomainParticipant，Topic，Publisher，以及DataWriter，并使用Data1和Data2分别在DataWriter中进行注册，获得两个句柄Handle1和Handle2，分别指向key为1和2的两个Topic实例，Data1和Data2。当取消注册时，DDS Tester使用了错误的句柄，即使用Data1和Handle2来取消注册，按照OMG DDS标准的描述，这时DDS应向应用程序返回“PRECONDITION_NOT_MET”，但实际返回为“OK”。

通过以上示例我们可以看到，被测DDS并没有完全按照OMG DDS标准进行实现。在实际项目中，这样的偏离可能导致系统不能达到设计预期的功能或者性能。DDS作为支撑起整车分布式系统的重要的框架性软件，我们需要谨慎的评估每一个对需求的实现偏离，因为其影响的范围可能并不局限于某个应用程序或某个应用场景，它可能影响的是整个分布式系统。

DDS协议测试套件中的测试用例能够在实际系统环境下遍历几乎所有应用程序接口，以及所有可能出现的调用接口的参数组合情况，并且能够评估整个系统在不同场景下的性能表现，实现了对DDS中间件的全面和深入的测试和评估。

总结

本篇文章探讨了DDS中间件的测试策略，并介绍了北汇信息与臻融软件科技推出的测试套件，然后通过一个示例展示了测试执行和分析问题的过程。如果想了解更多关于DDS协议测试套件的信息，欢迎联系我们。在过去的一年，除本文所介绍DDS协议测试，北汇落地实践了若干DDS相关的测试开发项目，包括基于OEM定制需求的DDS通信测试、S2S测试、DDS应用类测试，后续会有相关的文章持续与大家分享，敬请关注。