DDS测试策略探讨与协议测试工具介绍
软件定义汽车对测试的影响
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中间件来源或版本存在差别，互操作性测试也将是十分必要的。
除了互操作测试，另一个更重要的
