当前，面向服务的软件架构（SOA）在车载软件中占据越来越重要的位置，通信中间件便是其落地的关键环节之一。数据分发服务（DDS）在汽车领域的优势逐渐凸显，但关于DDS在车辆上部署与应用，文献却鲜有提及。文章针对数据分发服务，详细介绍了其基本原理、发布订阅模型和服务质量策略。接着介绍了DDS通信的整个过程，及DDS在车辆上部署的三种不同形式。最后以FAST DDS为例，详细介绍了DDS在车辆上部署的具体流程。基于数据分发服务的通信中间件在车辆上具有非常广泛的应用前景。
当前，我们正身处于汽车行业向电动化、智能化、网联化、共享化转型的浪潮之下，智能电控、智能驾驶、智能互联、智能出行深刻影响着人们的生活与思考方式，智能网联汽车已经成为引领我国汽车产业转型升级的战略方向[1-2]。随之而来的车辆电子电气架构向区域集中化靠拢，车载软件趋向更高融合度和复杂度，海量数据向云端迁移，软件定义汽车已成为行业发展的趋势。
面向服务的软件架构也越来越受到各大汽车厂商的青睐。基于新的架构模式，功能业务可以基于服务做灵活拓展，业务部署的灵活性和业务更新的快捷性都有质的提升。这些都对车辆的通信服务提出了更高的要求。一直沿用的AUTOSAR CP已经无法满足车辆通信的要求，面向服务的中间件也越来越引起人们的重视。
在分布式系统中，中间件指的是位于操作系统和应用程序之间的软件层。它通过对计算平台软硬件的抽象，并提供统一接口，简化了分布式系统的开发过程。使用中间件带来最直接的好处就是实现了应用层和底层的解耦，应用层开发人员可以忽略芯片、传感器等硬件的差异，从而高效、灵活地将上层应用及功能算法在不同平台上实现、迭代、移植。从这点来看，AUTOSAR也可以认为是一种中间件。
1 数据分发服务框架结构及特点
1.1 数据分发服务简介
目前主流的面向服务的中间件有数据分发服务（Data Distribution Service, DDS）、基于IP的可扩展面向服务的中间件（Scalable service-Oriented MiddlewarE over IP, SOME/IP）、消息队列遥测传输协议（Message Queuing Telemetry Transport, MQTT）。DDS是由对象管理组织（Object Manage- ment Group, OMG）制定的一种面向服务的通信中间件协议。采用发布订阅模型，强调以数据为中心，提供多种服务质量策略（Quality of Service, QoS），以保障数据实时、高效、灵活地分发，可满足各种分布式实时通信的应用需求[3-5]。
DDS在国防、航天、电网、医疗、能源等领域取得大量成功的应用，其优良的性能经过了长期的验证。在汽车领域，早在2018年，AUTOSAR AP在通信管理模块中加入了DDS技术；ROS2、Apollo CyberRT的底层也是基于DDS协议；Orin、Xavier等面向自动驾驶的系统级芯片（System On Chip, SOC）上也都预留了DDS的接口。DDS已被奥迪、大众等多家原始设备制造商（Original Equipment Manufacturer, OEM）厂商应用于智能驾驶、泊车充电、仿真测试平台等场景；国内的造车新势力小鹏汽车等也已经将DDS技术应用到量产车型上。
DDS能够实现低延时、高可靠、高实时性的数据融合服务，能够从根本上降低软件的耦合性、复杂性，提高软件的模块化特性，融合了DDS的汽车软件能够更好地运行在下一代汽车的体系架构中，更能降低开发的成本、缩短研发时间，更快地将产品推向市场。
DDS标准是一种中间件协议和以数据为中心的连接框架，它可以将分布式系统的组件集成在一起。DDS能够实现低延迟、高可靠、高实时性的数据融合服务，能够从根本上降低软件的耦合性、复杂性，提高软件的模块化特性，数据分发DDS 是OMG提供的用于以数据为中心的连接的中间件协议、连接框架和应用, 应用程序接口（Application Programming Interface, API）标准。它继承了分布式系统的组件，提供了低延时的数据连接、极高的可靠性和可扩展的体系结构，满足业务和任务关键型应用程序的需求[6]。与SOME/ IP、MQTT相比，DDS具有以下特点：
1）SOME/IP 是针对汽车领域的中间件，在车载领域已经应用了较长的时间。MQTT适用于低带宽及不稳定的网络，但它依赖于一个中央代理。DDS本身是一个工业级别的通信标准，适用于多种的应用场景，但用在汽车领域时可能需要做专门的裁剪。
2）相比于SOME/IP，DDS引入大量标准内置特性，在灵活性、可伸缩性等方便更具优势。
3）SOME/IP主要采用远程过程调用（Remote Procedure Call,RPC）的通信方式，服务器（server）和客户机（client）之间仍有一定的耦合性。而DDS采用发布/订阅机制，实现了通信双方在时间、空间和数据通信上的多维松耦合。
4）SOME/IP没有定义QoS机制，只能保证数据可靠，不能保证延迟。MQTT也具有保证稳定传输的机制的，但其仅支持QoS0、QoS1、QoS2的QoS策略。DDS具有丰富的QoS策略，能够满足高复杂性、高灵活性的数据流要求。
5）SOME/IP基于传输控制协议（Transmission Control Protocol, TCP）或用户数据包协议（User Datagram Protocol, UDP），只能在基于网络层为IP类型的网络环境中使用。而DDS基于实时发布订阅协议（Real-Time Publish-Subscribe, RTPS）可以有多种实现，且DDS独有的DDS Security、DDS Web功能可以为用户提供车-云-移动端一站式的解决方案。
1.2 以数据为中心的发布订阅模型
如图1所示，DDS内所有成员都被称为实体。以数据为中心的发布订阅（Data Centric Publish Subscribe, DCPS）模型基于全局数据空间（Global Data Space, GDS）的概念，所有对该空间内数据感兴趣的节点都可以接入，这在很大程度上提升了中间件的效率。
图1 DDS组成模型
DDS使用域（Domain）将网络划分为不同的网络分组，域由域号（Domain_ID）唯一标识，只有在同一个域内的通信实体才能通信。域内的参与者（Participant）是参与通信的最小单元，由参与者序号（Participant_ID）唯一标识，包含若干发布者（Publisher）、订阅者（Subscriber）和注册主题（Topic），负责创建、删除和管理这些实体。任何DDS应用都必须首先获取域参与者，然后通过域参与者获取其他服务，如发布者、订阅者、主题等。
发布者至少包含一个数据写入者（Writer），并负责创建、删除和管理数据写入者。同样，订阅者至少与一个数据读取者（Reader）关联，并负责创建、删除和管理数据读取者。数据写入者负责将发布者对应主题的数据写入数据存储区中，在发布者和QoS共同作用下发布实际的消息数据。数据读取者可采用同步、异步、非阻塞等订阅方式获取订阅者接收到的数据。
主题是数据发布者和数据读取者相互通信时的约定，必须包含主题名称和主题类型两个属性。每个数据发布者、数据读取者必须与一个主题绑定，相互通信的数据发布者、数据读取者之间的主题数据类型必须相同，且QoS必须匹配。
1.3 服务质量策略
QoS是一种网络传输策略，应用程序指定所需要的网络传输质量行为，QoS服务实现这种行为要求，尽可能地满足客户对通信质量的要求，DDS定义QoS策略使其对复杂网络环境的适应性和鲁棒性大大增强，优化网络传输质量[9-11]。
DDS规范定义了丰富的服务质量策略，标准中目前有22种，但目前一些DDS版本实现已经能支持50种以上的QoS策略，包括传输的可靠性、数据的持久性、资源限制等。用户可以通过XML文件配置等方式完成QoS的配置。
如图2所示，所有的DDS实体都可以绑定相应的QoS策略，其可以作用的对象如图2所示。QoS特性的支持使DDS非常适用于数据类型丰富且功能需求多样的场景。
用户可以通过设置QoS策略来控制数据在应用程序之间共享的方式，以满足不同场景下应用程序对功能和性能需求。数据读取者所属的订阅者和数据写入者所属的发布者的分区表达式应该匹配，且数据写入者提供的QoS策略应该超过或匹配数据读取者请求的策略，数据读取者才能接收到数据写入者发送的数据。如QoS中的可靠性（RELIABILITY），有可靠（RELIABLE）和最高效（BSET_EFFORT）两个选项。如果设为前者，当数据读取者由于各种原因无法收到数据时，样本数据会进行重发，保证数据读取者能收到数据；如果设为后者，则无法保证数据接收的完整性。
图2 DDS QoS策略
图3 DDS通信过程
首先启动DCPS层信息仓库来创建和初始化DDS全局数据空间，基于域ID创建域。然后，数据发布者和订阅者分别创建域工厂，域参与者，然后注册数据类型（DataType），通知DDS生成相关主题，DDS根据数据类型定义主题并完成QoS设置。发送方创建主题、布者和数据写入者；接收方查找主题，创建订阅者和数据读取者。
当数据接收方要订阅某一主题时，DDS会自动查找主题下的发布者，并将订阅者的IP地址发送给发布者，发布者会询问订阅者是否建立连接，订阅者回复确认连接后，发布者和订阅者双方连接完成，发布者设置QoS并发布最新的数据，DDS接收到数据，比较QoS，适时将数据传递给订阅者。
其中，数据接收方和发送方建立连接的过程称为DDS的发现过程。它主要分为参与者发现阶段（Simple Participant Discovery Protocol, SPDP）和端点发现阶段（Simple Endpoint Discovery Protocol, SEDP）。在参与者发现阶段，用于实现参与者之间的相互发现过程。在端点发现阶段，用于实现参与者内部端点之间的相互发现过程。发现机制主要有简单发现、静态发现、发现服务器、手动发现四种。
3 数据分发服务在车辆上的应用
目前，车辆上的通信大多数是采用AUTOSAR的架构。AUTOSAR CP主要应用于对于实时性、功能安全要求高，算力要求低的场景，如底盘控制，发动机控制等传统电子控制单元（Electronic Control Unit, ECU）。AUTOSAR AP主要应用于对算力要求较高、对实时性和功能安全要求稍低的场景，如自动驾驶域、智能座舱等新型域控制器。
目前主流的芯片设计方案采用异构核方式，通过把AP部署在高性能核上完成高性能运算指令，CP部署在实时性核上完成实时性要求较高的控制指令。
DDS在车辆上的应用处于刚起步阶段。简单来说，DDS在车辆上的部署主要有三种方式。第一种是类似于ROS2或Cyber RT，对DDS进行封装后，直接将DDS部署在操作系统上，在DDS的上层部署各个应用层模块，如图4所示。
图4 DDS直接部署
第二种是依托AUTOSAR AP平台，将DDS部署在AP的Ara::com模块中，如图5所示。由于AUTOSAR AP已经能支持DDS的集成，基于AUTOSAR分层架构，DDS的部署和SOME/IP一样对于应用层是透明的。通过不同的网络绑定，DDS便能较为快捷地集成在AUTOSAR AP中。
第三种，面向资源受限设备的DDS集成方案，即将DDS部署在微控制器（Micro Control Unit, MCU）上。这样MCU便能通过DDS与其他的DDS网络通信实现信息交互。而传统的MCU一般是基于AUTOSAR CP开发的，而目前CP平台仅支持SOME/IP的功能，并不支持DDS的集成。另外，一般基于C++版本实现的DDS资源占用率较高，并不适合部署在资源受控的微控制器上，因此，需要开发DDS的轻量化版本。方式之一是将DDS的功能实现在复杂设备驱动模块，实现与AUTOSR CP的集成，如图6所示。
图5 DDS集成AUTOSAR AP
图6 DDS集成AUTOSAR CP
一个DDS在车辆上部署的例子如图7所示；该车型共使用地平线J5和TI的TDA4共两块芯片。其中在J5直接部署DDS；在TDA4的A核上部署集成在AUTOSAR AP上的DDS，R核上部署集成在AUTOSAR CP上的DDS。两块芯片通过车载以太网进行连接，它们之间的通信方式有UDP、共享内存（SHM）、零拷贝（ZeroCopy）及跨核通信等。
图7 DDS在某车型上的部署
图8 DDS在车辆上的部署流程
图9 用户定义的数据类型
表1 定义数据类型得到的文件
图10 程序运行结果
END
