随着汽车电动化、智能网联化的不断发展，汽车控制系统将面临大量功能增加及技术升级，其中的电子电器架构逐渐趋向于中央计算集中化。针对高级驾驶辅助系统（ADAS）的自动泊车功能，对基于车载以太网的分布式实时通信（DDS）协议开展架构设计，通过多种异构传感器信息的采集和传输，实现自动泊车功能数据的实时交换。从实车检测效果来看，该设计方案可以满足当前驾驶辅助系统自动泊车功能的需求。

0 前言

目前，国内汽车驾驶辅助系统控制器之间通信大多采用控制器局域网络（CAN）总线协议或带灵活可变数据波特率的控制器局域网络（CAN-FD）总线协议，少数采用可扩展面向服务的IP 中间件（SOME/IP）协议。随着汽车智能化、网联化的发展，大量数据需要高速传输和交换，且对数据的可靠性要求也越来越高，CAN 总线协议已经逐渐满足不了大量数据传输的需求，SOME/IP 协议也满足不了大数据、多节点、高质量服务的应用场景，因此分布式实时通信（DDS）协议作为多域控制器之间的通信，被逐步应用于汽车电子系统中[1］。

DDS 协议是一套通信协议和应用程序编程接口的标准，其基于发布者和订阅者模型，提供了以数据为中心的连接服务。DDS 协议的功能介于操作系统和应用程序之间，使得各控制模块之间可以互相通信，且提供了低延迟、高可靠的通信，以及可扩展的架构。

由于DDS 协议体量较大且占用处理器资源较多，所以在汽车高级驾驶辅助系统（ADAS）方面使用较少。DDS 协议对设计和性能的要求比较高，主要体现在处理器的选型、DDS 协议接口定义语言（IDL）设计和服务质量（QoS）设计部分。本文通过在TDA4VM 处理器上对基于ADAS 自动泊车功能的DDS 协议进行设计，从而使DDS 协议的大体量可以通过合理设计IDL 和QoS 来解决，以满足在车辆自动泊车功能方面的应用需求。

1 系统设计

用于ADAS 自动泊车功能的DDS 协议系统设计如图1 所示。由图1 可以看出，在ADAS 控制器（TDA4VM 处理器）上设计自动泊车功能是以DDS 协议来实现通信的，ADAS 控制器与动力底盘控制器之间通过CAN-FD 协议实现相互通信，其中SOC 为系统级芯片，MCU 为单片机。

图1 基于ADAS 自动泊车功能的DDS 协议的系统设计

自动泊车功能的数据传输设计主要是将泊车功能的输入、输出信号通过ADAS 控制器内部的DDS 协议传输到动力底盘控制器上。因此，在DDS 设计过程中，需要注意ADAS 控制器中的SOC 端和MCU 端DDS 协议的IDL 设 计 和QoS 设计，以及如何通过合理的IDL 和QoS 设计使得ADAS 自动泊车功能能够满足给定的功能需求和性能需求[2］。

2 DDS 协议设计技术

基于ADAS 自动泊车功能的DDS 协议设计主要是在TDA4VM 处理器的R5F 内核与A72 内核进行设计部署，具体包括TDA4VM 处理器的DDS协议设计、DDS 协议中IDL 设计、DDS 协议中QoS设计这3 个部分。本文基于ADAS 自动泊车功能DDS 协议的部分设计进行技术分析。

2.1 TDA4VM 处理器的DDS 协议设计

ADAS 控制器采用的是德州仪器公司生产的TDA4VM 处理器。该处理器的优点是多核异构且选用适合的内核完成相应的任务，此外专用硬件加速器也可以处理特定任务，从而在性能、功耗和成本上达到最佳平衡。该处理器共有11 个内核，使用其中8 个内核实现ADAS 功能，分别是6 个R5F内核（其中2 个R5F 内核属于MCU 域，4 个R5F 内核属于MAIN 域（主域））和2 个A72 内核（属于MAIN 域），这8 个内核的通信采用DDS 协议实现。DDS 协议是基于操作系统和以太网协议才能实现通信功能的。

将辅助驾驶功能的需求部署在TDA4VM 处理器的不同内核上[3］，推荐方案如图2 所示。将高算力的辅助驾驶功能或者传感器采集（例如摄像头、雷达、全球定位系统（GPS）、惯性测量单元（IMU）和地图等）部署在2 个A72 内核上，其中包含ADAS 的自动泊车功能。将需要具备功能安全的辅助驾驶功能或者是CAN 总线上的信号采集部署在MCU 域上，将不需要功能安全的辅助驾驶功能部署在MAIN 域的4 个R5F 内核上。

图2 TDA4VM 处理器上的DDS 部署方案

DDS 协议在TDA4VM 处理器上的部署情况如图2 所示。按照自动驾驶功能的需求，MCU 域上会有具备汽车安全完整性等级D 的要求，主要功能是对动力底盘相关的信号进行采集和处理；这些信号经过DDS 协议由TDA4VM 处理器内部以太网交换机传送给高算力的A72 内核，以供ADAS 自动泊车功能使用。MAIN 域上的4 个R5F 内核上主要部署了对ADAS 功能的监控及静默升级等功能。

2.2 DDS 协议的IDL 设计

IDL 是一种描述性语言，以独立于编程语言和操作系统处理器平台的方式来定义用于交互的数据类型和接口。本文采用DDS 协议的数据提供者和数据接收者IDL 设计数据格式。ADAS 的自动泊车功能与动力底盘控制通信的信号在TDA4VM处理器上通过MCU 域的R5F 内核和MAIN 域的A72 内核 使 用DDS 协 议 进行传输[4］，在 此 过 程中IDL 的设计是评判处理器资源消耗情况的关键。在IDL 的设计中，DDS 协议的主题数量是衡量处理器资源消耗的关键指标，主题数量越多，资源消耗越大。特别是MCU 域资源比较紧张，在使用DDS 协议时需要重点考虑MCU 端的IDL 设计对资源的消耗。

2.2.1 上通信号

设计MCU 域时，将CAN 总线上采集的动力底盘信号从MCU 域的R5F 内核上传输到MAIN 域的A72 内核上，此过程中传输的信号称为上通信号。

考虑到MCU 域的内存问题，且CAN-FD 总线上的数据较多，为了节省资源，将自动泊车功能的输入输出信号和采集到的动力底盘信号解析部署在A72 内核上。在MCU 域上只进行数据接收、数据防丢失设计和监控接管。上通信号的IDL 设计方案按照CAN-FD 的信息结构格式来设计IDL 文件，IDL 文件在设计结构中包括CAN-FD 的ID 号、CAN-FD 报文周期、CAN-FD 报文长度和CANFD 报文的64 个字节数据。此设计方案对DDS 协议在MCU 域的部署来说只使用了1 个主题，从而节省了DDS 协议的资源消耗，也提高了MCU 域的运行效率。

2.2.2 下通信号

设计SOC 端时，对摄像头、雷达、GPS 和IMU等信号进行采集并融合处理，将相关的动力底盘信号传输到MCU 域的R5F 内核上。将A72 内核上的服务化数据通过DDS 协议传输到MCU 域上，此过程中出现的信号称为“下通信号”。

ADAS 自动泊车功能的下通信号主要是动力底盘信号，需要具备功能安全的要求，所以A72 内核上对于信号的处理只做服务化后的传输，在MCU 域上进行信号的解析和传输。下通信号的IDL 设计按照ADAS 的自动泊车功能来设计动力控制模块，此模块由控制动力的信号结构体（包含速度、加速度、距离与档位信号）、控制横向信号的结构体（包含横向使能与方向盘角度信号）、控制纵向信号的结构体（包含纵向使能、刹车扭矩与速度控制信号）和驻车控制的枚举结构（包含使能手刹信号与取消手刹信号）4 个部分组成。完成模块设计后可对动力底盘进行控制。基于功能安全的需求，下通信号需要4 个主题来定义，由于数据量小，使得MCU 域的资源消耗不会太大，同时下通信号也具备了功能安全的要求。此设计方案使得MCU域的资源消耗与信号安全达到了相对的平衡。

2.3 DDS 的QoS 设计

DDS 协议拥有灵活的QoS 选项和配置属性，其中包括数据的可用性控制、数据的交付方式控制、数据的时效性控制、用户信息的定义和分发、网络和数据资源的控制。用户可通过QoS 策略来控制数据在应用程序之间共享的方式。用户可依据应用场景的需求，选择相应的QoS 策略来满足通信质量的需求。

DDS 协议的数据提供者和数据接收者中最常用的QoS 选项有可靠性、历史性、资源限制、持久性、传输延迟性与心跳周期。DDS 协议需要设计QoS 属性的有参与者、数据提供者、数据接收者和主题4 个部分。DDS 协议的QoS 设计在MCU 和SOC 上有不同的实现方法：MCU 是静态加载，会以代码配置形式写入MCU 的程序中；SOC 可以是动态加载也可以是静态加载，此处采用可扩展标记语言（XML）文件的形式进行动态加载，灵活性较高。DDS 协议中有默认的QoS 设计，可随着DDS协议的运行而运行，新设计的QoS 会覆盖默认的QoS 中的相同配置。

2.3.1 MCU 的QoS 设计

按照ADAS 自动泊车功能的需求，MCU 的数据提供者和数据接收者的QoS 设计需求有所不同。数据提供者的QoS 设计属性有资源限制设计、历史性设计、心跳周期设计3 个部分配置，其他属性选择默认设计。在资源限制中，最大样本实例数为3、最大实例数为1、最大样本数为3，资源限制的设计是为了让写入数据的速度与读取数据的速度相匹配。数据提供者资源限制的最大远程读取节点限制为2，最大写入通道数为2，如此设计是为了限制读取端最大的节点数。在历史性设计中，历史数据深度设置为3，这可保证数据丢失补偿。在心跳周期设计中，心跳周期设置为250 ms。可实现DDS协议中，实时发布订阅（RTPS）协议包括对已丢失并重传消息的检测。

数据接收者的QoS 设计属性有资源限制设计、历史性设计2 个部分配置其他属性选择默认设计。在资源限制中，最大样本实例数为3、最大实例数为1、最大样本数为3，资源限制的设计是为了让写入数据的速度与读取数据的速度相匹配。数据接收者资源限制的最大远程读取节点限制为2，最大写入通道数为2。此设计是为了限制读取端最大的节点数。

2.3.2 SOC 的QoS 设计

根据ADAS 自动泊车功能的需求，将QoS 中的数据提供者和数据接收者XML 文件进行重新设计，保证SOC 的所有数据提供者和数据接收者的QoS 配置项都相同。其中，将QoS 的历史数据跟踪深度设置为3，可记录3 次历史数据且对数据丢失进行了补偿。此外也加入了选择可靠值属性，该设计方案是对数据的DDS 协议传输进行了加固，并将持久性的QoS 配置项设计为瞬态局持久性，这对数据提供者来说就是将发送的数据写入历史记录中且保存已发送数据，当数据出现丢失时，会将历史记录中的数据重新发送出去。

3 结果与分析

通过对DDS 协议在TDA4VM 处理器上的部署设计、DDS 协议的IDL 设计、DDS 协议的QoS 设计完成了MCU 域的R5F 内核和MAIN 域的A72内核的相互通信，实现了ADAS 自动泊车功能，同时使用基于DDS 协议的性能测试工具进行测试[5］。结果显示，基于DDS 协议从MCU 域到SOC 端（A72 内核）的通信测试结果延迟时间在2～4 ms。从实车检测效果来看，该方案可以满足当前ADAS自动泊车功能的需求。

4 结语

基于ADAS 自动泊车功能的DDS 设计，在TDA4VM 处理器上部署DDS 协议，能够实现数据的集中化分发，且在MCU 域上进行DDS 协议部署，可在系统资源紧张的情况下做到大量数据的接收和分发，从性能角度大幅优化了MCU 端DDS 协议带来的影响，为后期多域和跨域融合使用DDS 协议的设计奠定了基础。未来，最大的设计挑战可能还是MCU 端，由于系统资源紧缺且DDS 协议又是一个比较重要且耗费资源的协议，因此当DDS 设计的模块化变多时，MCU 端的工作负担会加重，从而影响自动驾驶功能在MCU 域上的运行效率。