基于DDS,的车载分布式系统的测试策略探讨
时间：2023-03-10 17:35:05 来源：千叶帆 本文已影响人
王昊天
（上海北汇信息科技有限公司， 北京 102208）
“中间件”是一个比较抽象和宽泛的概念，它并不特指一种具体的技术，其概念起源于复杂分布式软件系统的开发，其目的是实现软件组件之间进行数据交换，使软件组件之间实现解耦。这种数据交换通常是通过网络进行，而中间件的任务就是确保网络本身对软件组件是透明的。比如我们所熟知的SOME/IP就是一种典型的中间件技术实现。使用中间件能够简化系统的开发，提高管理和测试效率。
车载网络通信的中间件有其特殊之处。车载软件系统可能十分复杂，这些系统可能分布在一个ECU的不同模块里，或在同一个ECU模块的不同进程中，也可能分布在不同ECU中。这些不同的模块或不同的ECU可能使用不同的软件架构和操作系统，比如符合POSIX要求的类Unix操作系统（如Linux 和QNX）、Classic AUTOSAR 系 统、Adaptive AUTOSAR系统等，中间件在这些不同的系统之间起到了重要的桥梁作用。
SOME/IP是最早应用在汽车上的通信中间件，在2014年实现了量产，但是近年来汽车行业对中间件技术的探索并未停止，目前主要有两个方向。
1） 对SOME/IP进行功能上的扩展，其主要的思路是给SOME/IP添加TLV（Type Length Value） 支持，以实现更好的灵活性。我们知道SOME/IP的序列化采用了比较静态的定义方式，比如SOME/IP的Payload中的参数的类型、顺序、字节序等，都是在配置文件中静态定义的，那么应用程序在使用这些类型时，必须要严格遵循配置文件中的定义去解析数据。所谓TLV，简单来说就是给每个参数添加一些附加的自描述信息，比如类型信息、长度信息，这样应用程序可以依赖这些自描述信息动态解析参数。对TLV的支持将使软件系统进一步解耦，让应用程序以更灵活的方式使用SOME/IP。但是灵活性和高效率往往是鱼与熊掌不可兼得，引入TLV的缺点也是显著的，额外的“标签”信息将占用更多的Payload空间，这会降低带宽的利用率，对实时性有一定影响（尤其是对于资源有限的小型ECU）。
2） 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目前并不支持，尽管目前有厂商使用复杂驱动（CDD） 在Classic AUTOSAR平台集成了DDS，但这并不是一种完美的解决方案。首先Classic AUTOSAR平台往往资源有限，同时又有严苛的实时性要求，在其之上运行DDS显得代价高昂；
其次，通过复杂驱动意味着和硬件强相关，这会使软件丧失可移植性，对于DDS这种基础软件组件，厂商要付出更多的开发、测试和维护的成本，这实际上也不符合AUTOSAR的初衷。
尽管目前有一些技术问题需要解决，但不可否认的是，DDS依然前途光明，国内很多OEM已经将DDS作为下一代电子电器架构的基础通信技术，甚至已经实现了量产。
3.1 DDS协议一致性测试
DDS本质上是一种传统的工业基础软件，用户购买了软件，然后在系统里每个节点上进行“安装”。所以我们可以看到很多商用的DDS软件产品，在其内部的测试流程中，有一个很重要的环节是“安装测试（Installtests）”，目的是验证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规范中没有要求的额外功能特性，这种情况可能也会引发互操作问题。基于这种考虑，用户根据实际情况对系统进行针对性的互操作测试也许是更好的选择。
3.2 DDS配置测试
DDS一个很大的特点是支持“开箱即用”，即用户不需要对系统做任何特殊配置即可使用DDS，比如IP地址、端口号、DDS系统中每个Participant、DataReader和DataWriter的ID等，所有的这一切都是由DDS/RTPS进行自动配置，动态地发现系统里的节点。用户只需要在IDL文件中定义自己的类型，就可以进行应用程序的开发，这对网络架构设计者和应用开发者都非常友好。
为了满足不同系统对中间件功能和性能不同的需求，DDS也提供了多种方式允许用户对DDS的行为特性进行进一步调节，比如QoS、RTPS通信层面的配置等。如果说用户进行了这些配置工作，我们需要设计测试方案来验证这些配置的一致性。这一部分可基于VectorCANoe option Ethernet，通过编程和定制开发来实现。使用Vector提供的多种以太网接口卡，编写脚本进行RTPS消息的解析，并从中提取这些配置信息，验证其与用户配置规范的一致性。图1为DDS配置测试部分条目参考，图2为基于CANoe实现的DDS配置测试工程示例。
图1 DDS配置测试部分条目参考
图2 基于CANoe实现的DDS配置测试工程示例
服务接口测试的核心工作是服务请求的仿真，这意味着测试工具要集成DDS中间件，使其能够仿真客户端的行为。遗憾的是，截至此文撰写时，行业内没有针对DDS服务测试的成熟工具可以使用。
我们可以使用多种方案来完成DDS服务接口测试，比如利用CANoe的Socket或FDX接口，或其他测试框架（如Robot Framework和ECU TEST），开发“DDS适配器”，来完成服务的仿真和测试。如图3所示。
图3 基于CANoe FDX实现的 “DDS适配器” 示意图
随着软件定义汽车和车载以太网的快速发展，传统IT行业很多分布式系统技术也逐步运用到汽车中，比如本文提到的中间件技术。然而引入这些不同的技术时，我们必须意识到，汽车除了是一个智能终端设备，它的本质属性是交通工具，在把汽车交付到消费者手中之前，厂商应进行充分的验证和测试，保证产品的品质。本文介绍了中间件的概念以及SOME/IP、DDS等技术，对DDS以及基于DDS的SOA系统的测试策略进行探讨，欢迎各位读者提出宝贵意见，与我们进一步交流。
猜你喜欢 中间件定义规范 来稿规范北部湾大学学报(2022年1期)2022-06-22来稿规范北部湾大学学报(2022年2期)2022-06-21PDCA法在除颤仪规范操作中的应用现代仪器与医疗(2021年4期)2021-11-05来稿规范北部湾大学学报(2021年4期)2021-04-28RFID中间件技术及其应用研究电子制作(2018年14期)2018-08-21基于Android 平台的OSGi 架构中间件的研究与应用电子制作(2017年13期)2017-12-15成功的定义山东青年(2016年1期)2016-02-28中间件在高速公路领域的应用中国交通信息化(2014年4期)2014-06-05修辞学的重大定义当代修辞学(2014年3期)2014-01-21一种支持智能环境构建的中间件郑州大学学报（理学版）(2013年3期)2013-03-11 相关热词搜索：分布式，探讨，策略，
