“中间件”是一个比较抽象和宽泛的概念，它并不特指一种具体的技术，其概念起源于复杂分布式软件系统的开发，其目的是实现软件组件之间进行数据交换，使软件组件之间实现解耦。这种数据交换通常是通过网络进行，而中间件的任务就是确保网络本身对软件组件是透明的。比如我们所熟知的SOME/IP就是一种典型的中间件技术实现。使用中间件能够简化系统的开发，提高管理和测试效率。
车载网络通信的中间件有其特殊之处。车载软件系统可能十分复杂，这些系统可能分布在一个ECU的不同模块里，或在同一个ECU模块的不同进程中，也可能分布在不同ECU中。这些不同的模块或不同的ECU可能使用不同的软件架构和操作系统，比如符合POSIX要求的类Unix操作系统（如Linux和QNX），Classic AUTOSAR系统，Adaptive AUTOSAR系统等，中间件在这些不同的系统之间起到了重要的桥梁作用。
SOME/IP是最早应用在汽车上的通信中间件，在2014年由宝马率先实现了量产。但是近年来汽车行业对中间件技术的探索并未停止，目前主要有两个方向。
一是对SOME/IP进行功能上的扩展，其主要的思路是给SOME/IP添加TLV（Type Length Value）支持，以实现更好的灵活性。我们知道SOME/IP的序列化采用了比较静态的定义方式，比如SOME/IP的Payload中的参数的类型，参数的顺序，字节序等，都是在配置文件中静态定义的，那么应用程序在使用这些类型时，必须要严格遵循配置文件中的定义去解析数据。所谓TLV，简单来说就是给每个参数添加一些附加的“标签”信息，比如类型信息，长度信息，这样应用程序可以依赖这些“标签”信息动态解析参数。对TLV的支持将使软件系统进一步解耦，让应用程序以更灵活的方式使用SOME/IP。但是灵活性和高效率往往是鱼与熊掌不可兼得，引入TLV的缺点也是显著的，额外的“标签”信息将占用更多的Payload空间，这会降低带宽的利用率，对实时性有一定影响（尤其是对于资源有限的小型ECU）。
二是DDS（Data Distribution Service）。DDS是目前国防，航空等领域广泛应用的通信中间件技术，我们曾在往期文章中介绍过。DDS的核心规范有两个，分别是DDS specification，以及 DDSI-RTPS specification。DDS specification定义了DDS的应用程序接口和基本行为，DDSI-RTPS specification定义了DDS的传输实现，目的是实现不同DDS产品的互操作性。除此之外，DDS在2017年发布了DDS-RPC规范，使得DDS能够基于发布-订阅模型实现远程过程调用（RPC），满足SOA架构的需求。
DDS和SOME/IP是在不同的应用场景和不同的需求下诞生的技术，所以它们之间注定有很大的区别。DDS有着更丰富的特性，尤其是对QoS的支持。但是相对于SOME/IP，DDS也有显著的不足。首先，RTPS消息头部十分冗长，这会降低传输效率和实时性。另一方面，汽车作为一个相对封闭的系统，为了降低功耗，经常需要频繁的唤醒和休眠，这就要求系统有非常快的启动速度，而DDS并不是为这种场景设计的，DDS可能必须经过深入的优化才能满足严苛的时间要求。最后，DDS目前只能在Adaptive AUTOSAR框架下运行，Classic AUTOSAR目前并不支持，尽管有厂商使用复杂驱动（DDS）的方式在Classic AUTOSAR平台集成了DDS，但这并不是一种完美的解决方案。首先Classic AUTOSAR平台往往资源有限，同时又有严苛的实时性要求，在其之上运行DDS显得代价高昂；其次，通过复杂驱动意味着和硬件强相关，这会丧失软件的可移植性，对于DDS这种基础软件组件，厂商要付出更多的开发、测试和维护的成本，这实际上也不符合AUTOSAR的初衷。
尽管目前有一些技术问题需要解决，但不可否认的是，DDS依然前途光明，国内很多OEM已经将DDS作为了下一代电子电器架构的基础通信技术，甚至已经实现了量产。
DDS的测试策略和方案探讨DDS协议一致性测试
DDS本质上一种传统的工业基础软件，用户购买了软件，然后在系统里每个节点上进行“安装”。所以我们可以看到很多商用的DDS软件产品，在其内部的测试流程中，有一个很重要的环节是“安装测试（Install tests）”，目的是验证DDS产品在常见平台的兼容性。而用户在集成了DDS之后并不会过多的对DDS产品本身进行验证，更侧重应用层测试。所以这就造成了目前DDS生态里缺少像TC8这种行业内标准化的测试规范，以及相应的测试工具。
车载电子电器系统的计算平台五花八门，不同OEM，不同车型平台，不同项目，其搭载的系统平台（包括芯片架构，操作系统等）可能都有不同，这些不同的平台相互的组合情况更难以计数。这种背景下，只依赖DDS产品供应商内部的“安装测试”似乎显得不足。
此外，正如上文所讨论，为了让DDS的功能和性能更符合车内通信的要求，用户需要对DDS产品进行定制裁剪和优化，尤其是针对非标准计算平台实现的DDS（如Classic AUTOSAR平台），在这个过程中用户需要对产品进行充分的测试，才能保证裁剪或优化后的软件仍然是可靠的。
不同DDS产品之间的互操作也是不可忽视的问题。OMG组织并不提供DDS软件实现，各厂商可以根据该标准实现自己的DDS。尽管DDS发布了DDSI-RTPS规范来保证不同DDS实现之间的互操作性，但是这里提到的“互操作性”，可能并没有经过充分的测试和验证。尽管软件开发者可能会在内部的产品测试阶段进行与其他产品的互操作测试，但是这很难覆盖DDS的所有功能特性，也很难覆盖目前市面上所有DDS产品的所有可能出现的组合。此外，DDS的软件实现经常与OMG规范产生偏离，比如DDS实现不支持某些OMG规范中的特性，或者DDS实现中增加了OMG规范中没有要求的额外的功能特性，这种情况可能也会引发互操作问题。基于这种考虑，用户根据实际情况对系统进行针对性的互操作测试也许是更好的选择。
为了满足这种需求，北汇信息正与合作伙伴开展DDS一致性测试测试包的开发工作，以实现DDS产品在特定平台下的功能特性一致性验证，具体包括：
- API接口测试
- DDS基本行为测试
- QoS测试
- DDS Discovery测试
- X-Types测试
- DDS-Security测试
- 互操作测试
- 性能测试
DDS一个很大的特点是支持“开箱即用”，即用户不需要对系统做任何特殊配置即可使用DDS，比如IP地址，端口号，DDS系统中每个Participant，DataReader和DataWriter的ID等等，所有的这一切都是由DDS/RTPS进行自动配置，动态的发现系统里的节点。用户只需要在IDL文件中定义自己的类型，就可以进行应用程序的开发，这对网络架构设计者和应用开发者都非常的友好。
为了满足不同系统对中间件功能和性能不同的需求，DDS也提供了多种方式允许用户对DDS的行为特性进行进一步调节，比如QoS配置，RTPS通信层面的配置等。如果说用户进行了这些配置工作，我们需要设计测试方案来验证这些配置的一致性。这一部分可基于Vector CANoe option Ethernet，通过编程和定制开发来实现。使用Vector提供的多种以太网接口卡，编写脚本进行RTPS消息的解析，并从中提取这些配置信息，验证其与用户配置规范的一致性。
图1 DDS配置测试部分条目参考
图2 基于CANoe实现的DDS配置测试工程示例
DDS服务接口测试
服务接口测试的核心工作是服务请求的仿真，这意味着测试工具要集成DDS中间件，使其能够仿真客户端的行为。遗憾的是，截至此文撰写时，行业内尚无针对DDS服务测试的成熟的货架式工具。
北汇信息基于积累的工程经验，通过定制化开发，目前可提供多种服务仿真方案以完成DDS服务接口测试。比如利用CANoe的Socket或FDX接口，或其他测试框架（如Robot Framework和ECU TEST），开发“DDS适配器”，来完成服务的仿真和测试。
图3 基于CANoe FDX实现的“DDS适配器”示意图
总结
随着软件定义汽车和车载以太网的快速发展，传统IT行业很多分布式系统技术也逐步的运用到汽车中，比如我们今天提到的中间件技术。然而引入这些不同的技术时，我们必须意识到，汽车除了是一个智能终端设备，它的本质属性是交通工具，在把汽车交付到消费者手中之前，厂商应进行充分的验证和测试，保证产品的质量。本篇文章介绍了中间件的概念，以及SOME/IP，DDS等技术，结合北汇信息多年来在电子电器测试方面的经验，对DDS以及基于DDS的SOA系统的测试策略进行探讨，并简单介绍了北汇信息提供的测试方案，后续将给大家带来DDS一致性测试等内容的专题介绍，欢迎各位读者提出宝贵意见，与我们进一步交流。