融合轻量级DDS的智能车通信架构设计

张兴旺，王思山，周海鹰，张昊宇，宋昊江

（湖北汽车工业学院 汽车工程师学院，湖北 十堰 442002）

随着汽车智能化、网联化、共享化、电动化的快速发展，现代汽车正经历从代步工具到新一代移动智能终端的转变［1］。在此背景下，软件逐渐成为汽车创新的主要驱动力。传统分布式汽车电子电气架构的功能分散在各个ECU中且各ECU之间的依赖关系是静态的，网络结构复杂，代码逻辑冗余度较高［2］，在后期功能扩展和更新升级方面具有局限性，无法满足汽车产业发展的需求。整个汽车行业正在重新定义汽车电子电气架构，转向更易模块化的面向服务的架构（service-oriented architecture，SOA），让汽车真正成为新一代移动智能终端［3］。ROS2和Adaptive Autosar是2种符合SOA的实现方式，为适应汽车智能化和网联化和支持高复杂应用，两者集成了DDS 通信机制。针对ROS 大数据量传输性能瓶颈、中心化网络存在单点风险以及数据格式缺乏向后兼容等问题，百度Apollo对ROS进行改进与优化［4-5］，使用RTPS服务发现协议实现端到端的网络通信，取消Master作为中央数据交换的功能，但仍不满足自动驾驶系统对更高水平的稳健性和性能的需求。Maruyama Y［6］等人从延迟、吞吐量、线程数和内存消耗方面对ROS1 和ROS2 通讯机制进行了评估，但并未在实际智能驾驶汽车系统中评估DDS 的通信性能。Reke M［7］等人从自动驾驶的软件架构需求出发，提出基于ROS2的自动驾驶软件解决方案，并在不同自动驾驶场景中评估了其实时性和可靠性，但是所设计的自动驾驶软件架构中仍有部分传感器是以面向信号进行数据传输，在软件架构的灵活性、耦合性和实时性等方面依然存在局限性，不能满足未来汽车发展的需求。基于此，通过对SOA通信中间件对比分析，选择合适的DDS通信中间件，结合智能车环境感知设备构建了以数据为中心、松散耦合的新型智能车通信架构。

1 面向服务的智能车通信架构设计

1.1 通信架构模型设计

智能车环境感知单元如雷达、相机、定位模块以及执行机构作为客户端，SOA通信中间件将环境感知和执行控制等信息进行封装，以服务的形式传输至中央计算单元，与其他ECU 单元进行数据交互，构建1个具有服务内高内聚、可复用、服务间低耦合的灵活可变的系统。采用序列化/反序列化工具完成数据的传输，以发布/订阅为通信机制的可扩展性智能车通信架构模型如图1所示。

图1 智能车通信架构模型

1.2 SOA通信中间件的选择

SOA 是面向服务的架构，可实现软硬件解耦，解决了传统汽车电子电气架构的网络信号结构复杂、不同ECU 通信兼容性差、不便于软件空中升级、软件开发时间周期长和成本高等问题。目前主流的面向服务的通信协议有SOME/IP［8］、DDS［9］、MQTT［10］。SOME/IP是面向服务的可扩展的通信中间件，但并没有定义QoS 机制，依赖于应用程序和TCP/UDP 的机制来实现可靠性传输。DDS 是基于发布/订阅模型，可使用TCP和UDP传输协议，当使用UDP 组播时，UDP 传输效率比TCP 的传输效率更高。DDS与MQTT相比，DDS的主要优势是消息传输的动态性和灵活性，以及在具有大量节点的系统中的可伸缩性。MQTT 协议适用于低带宽及不稳定的网络，但该协议依赖于1 个中央代理，中央代理负责在发布者和订阅者之间传输信息。MQTT 协议具有保证稳定传输的机制，仅支持QoS0、QoS1、QoS2的QoS策略。而DDS支持丰富的QoS策略以及数据序列化等功能，不仅具有传输可靠性、低延迟和容错性，还提供了数据保存和元数据管理等功能［11］。因此采用DDS 作为通信中间件实现面向服务的智能车通信架构设计。

1.3 DDS的实现选择

DDS 是对象管理组织制定的发布/订阅标准，但并没有规定实现方式，常见的实现方式有RTI DDS、OpenSplice DDS和OpenDDS等。上述DDS实现方式资源占用较高，不适合在资源受限的微控制器使用。在选择中间件时，考虑到开源、许可证申请、后期开发与维护成本等因素［12］，因此采用面向极端资源受限设备的DDS 解决方案Micro XRCEDDS［13］。Micro XRCE-DDS客户端是完全动态无内存的，当执行完整的发布与订阅程序时，其内存消耗小于75 kB 的Flash 和2.5 kB 的RAM。此外还支持UDP、TCP 以及自定义串行传输方式，Micro XRCE-DDS 还为代理和客户端提供了1 个传输接口，为Micro XRCE-DDS 移植到资源受限的微控制器中提供了理论基础。

Micro XRCE-DDS 客户端部署在ECU 中，为ECU 赋能使其能够与规模较大的DDS网络通信交互。代理端部署在中央计算单元中实现客户端之间的网络动态发现，数据的转发，具有DDS实体创建与存储功能，其中央计算单元具有大数据量通信交互的处理能力，满足智能车整体通信所需的实时处理和通信质量的需求，同时也解决了资源受限的微控制器无法运行完整DDS实现的问题。

2 通信架构的实现

2.1 架构设计

为了满足资源有限的微控制器设备与标准DDS服务通信交互的功能需求，设计的智能车通信软件架构见图2。微控制器选择MPC5748G网关芯片［14］，Micro XRCE-DDS 使用Lwip 组件为XRCEDDS 应用程序开发提供框架。由于Micro XRCEDDS的可移植性，其客户端部署在MPC5748G中且在Lwip 上层运行，能够满足系统应用的实时性和可靠性要求［15］。客户端可实现登录会话及请求代理端创建发布者或订阅者等实体相关功能，另外负责数据的序列化与反序列化。中央处理单元选择嵌入式Linux 高性能计算机Xavier，Micro XRCEDDS 代理端部署在Xavier 中与客户端MPC5748G通过以太网传输，客户端向代理请求创建DDS 实体的操作，并且选择合适的数据流，例如Best-effort或Reliable 数据流。Micro XRCE-DDS 代理使用Fast-RTPS协议与DDS全局数据空间交互，进而与其他连接DDS全局数据空间的客户端通信。

图2 通信架构设计

2.2 Micro XRCE-DDS的适配

在S32 Design Studio 软件开发环境中新建工程，其处理器专家嵌入FreeRTOS 实时操作系统和Lwip 协议，添加相关组件并进行相应的配置。通过添加tcpip_middleware 组件配置Lwip 参数，完成Micro XRCE-DDS移植准备工作。

作为DDS 通信中间件须提供服务发现、序列化/反序列化和数据传输的功能，在Micro XRCEDDS移植前，应关注传输控制接口相关的函数并进行相关修改。MicroCDR文件夹包含实现消息的序列化/反序列化功能相关的源文件。DDS/Core文件夹的源文件主要负责日志记录、客户端请求代理端的操作，例如登录和关闭会话以及创建和删除参与者、发布者、订阅者等实体，同时为主题的类型以及名称提供类型支持。DDS/Core/Profile 的源文件主要负责发现代理和网络传输控制的功能。为实现Micro XRCE-DDS与Lwip协议相适配，需要修改源文件，其改动部分见表1。

表1 源文件主要修改部分

2.3 发布/订阅功能实现

发布和订阅之前，客户端调用uxr_init_session（）函数向代理发送创建会话、注册客户端等操作。在指定传输方式和创建会话成功后，创建Micro XRCE-DDS 实体层次结构，进行发布或者订阅主题。微控制器通过DDS 实体与标准DDS 服务通信，在创建实体的XRCE 操作中，Object ID 在客户端中代表1 个实体，每个创建实体的操作都返回1个请求ID，其操作标识符可以稍后用于将状态与操作相关联，然后被写入到reliable 或者best_effort流中，最后数据被发送到代理端。客户端在创建参与者实体后，使用话题操作注册Topic 实体。将XML 发送到代理，在DDS 全局数据空间中创建和定义包含名称和类型的主题，在参与者实体上创建发布/订阅实体及数据写入器或数据读取器。

对于发布功能而言，DDS实体创建成功后可使用写入函数将数据写入DDS 全局数据空间。uxr_prepare_output_stream（）函数将话题内容写入相应的数据流中，并完成主题内容匹配，然后初始化ucdrBuffer，在缓冲区中完成序列化主题内容。客户端调用uxr_run_session_time（）函数刷新所有通过传输发送数据的输出流，同时侦听来自代理调用关联回调（主题和状态）的消息，若侦听到数据，则向代理端请求写入操作，代理端数据写入者将数据写入数据空间。

对于消息订阅，首先创建DataReader 实体，调用读取函数，通过代理端将数据发送到客户端，读取DDS 全局数据空间中的数据。datareader_id 与接收数据的DataReader 实体相对应，delivery_control 参数决定了数据从代理端传递到客户端的方式。当订阅者从代理端接收到消息时，调用uxr_run_session_until_all_status 函数来保持客户端与代理端之间的数据通路，更新通过网络传输发送数据的输出流，监听代理端相关回调的消息。客户端向代理端发送READ_DATA子消息，数据读取器读取DDS全局数据空间中的数据，代理端返回DATA 子消息作为响应，其子消息包含所订阅话题的内容，消息发布/订阅程序流程如图3所示。

图3 发布和订阅流程

3 测试与验证

3.1 测试环境搭建

测试平台如图4 所示。采用Xavier 作为中央单元，与车规级芯片MPC5748G 组成域控制器（图4a）。以毫米波雷达ARS430、相机ZED2 和Ublox GPS 为环境感知单元，与底盘SCOUT MINI 组成智能小车测试平台（图4b）。

图4 测试平台

3.2 通信设计

为满足大流量数据对高带宽、低延时的需求，将Xavier、ARS430、MPC5748G 和交换机通过以太网连接并部署在同一局域网内。智能车传感器模块、SCOUT MINI以及测试接口连接方式见图5。

图5 智能车通信架构

传感器发布/订阅逻辑关系如图6 所示，在MPC5748G 中利用Micro XRCE-DDS 客户端对SCOUT MINI、GPS及遥控器传输的信息进行封装，并通过代理瑞发布到DDS数据空间中，其中话题“/remote_control”以10 Hz 发布遥控指令信息，“/gps”以4 Hz发布小车位置与速度信息。在ubuntu系统中配置ARS430 和ZED2 的相关驱动，两者通过Fast RTPS协议与代理端进行数据交互，ARS430以10 Hz 发布“/radar”话题，ZED2 以15 Hz 发布“/zed”话题。所有传感器采集到的环境信息都会传输到数据处理模块进行融合处理，处理后的数据通过Fast-RTPS 协议传输至代理端，由代理端将数据传到SCOUT MINI，MPC5478G 通过以10 Hz 发布/订阅“/scoutmini”话题与Xavier 进行数据交互来执行相应的动作。

图6 发布/订阅逻辑

3.3 性能测试

SCOUT MINI 与MCU 间采用CAN2.0总线进行数据传输，SCOUT MINI实时向MCU反馈当前系统状态、运动控制、电机驱动、里程计以及遥控器的信息。MCU 接收速率为1120 Byte·s-¹，ZED2 传输速率为13 Mbit·s-¹，Ublox的传输速率为5710 Byte·s-¹，ARS430 数据传输速率为24493 Byte·s-¹。试验在智能车各个传感器都正常运行的情况下进行。

为避免发布者和订阅者所在异构系统的时钟不同步，通过往返时间近似测量延迟，原理见图7。中央计算单元发布信息，然后发布端等待客户端MPC5748G将其返回，通过时间戳获得发布者的发送时间和订阅者的接收时间。时延计算公式为

图7 时延计算原理

式中：Li为第i个消息的时延；Tsen[i]为消息发送时刻；Trec[i]为消息回传到发布端的时刻；Lavg为n个消息的平均时延。为体现时延特征，在不同时间内的智能车通信运行结果中选取120 s的通信时延如图8所示。在智能车运行时间段内，端到端通信平均延迟小于3 ms，通信延迟方差趋近于0 ms，延迟抖动性良好，满足智能车内部通信的实时性要求。

图8 端到端通信延迟

4 结论

设计并实现了一种基于轻量级DDS 的智能车软件架构，选取Micro XRCE-DDS 作为实现智能车面向服务通信的中间件，并将其客户端适配到微控制器MPC5748G 中，中央计算单元Xavier 运行代理，使微控制器能够访问DDS全局数据空间，有效解决了资源受限设备不能运行完整DDS 的问题。其端到端的平均通信延迟小于3 ms，表明该系统具有良好的实时性。