| 编辑推荐: |
本文主要介绍了汽车以太网协议之DDS相关内容。希望对您的学习有所帮助。
本文来自于微信公众号汽车电子与软件 ，由火龙果软件Alice编辑、推荐。
|
|
1 背 景
1.1 EEA 架构演变
随着汽车中新的用例和技术的引入，车辆的电气/电子架构正在发生根本性变化，如下图。
-
分布式电子电气架构，每个功能对应一个独立的ECU, 例如：发动机ECU、雨刮器ECU等。
- 域集中式架构，随着自动驾驶、智能座舱等技术的不断发展，域控制器架构被提出来。其主要特点就是按照功能域区分，比如智能座舱域、自动驾驶域、动力域等。
- Zonal 架构，如下图，按物理位置或功能融合划分。由于当前自动驾驶技术逐步向L4 发展，所以为了达到期望的自主性和连接性水平。涉及到了了以下变化内容：
- 传感器数量急剧增加，数据量的膨胀式增加。
- 需要计算变得更加复杂，需要更强大的计算平台。
- 连接它们所需的布线成本也影响着解决方案的总体成本。
- 车载网络正从功能逻辑分布转向物理区域分布。该架构由多个区域网关控制器组成，这些控制器处理与一个物理区域的传感器和执行器的通信，组合每个设备所需的网络协议。同时，这些区域网关通过以太网骨干网彼此连接，并与中央
CPU 或高性能计算机连接。
1.2 通信方式演变
与EEA 架构的演变相同。通信需求也逐步从信号导向通信、服务导向通信、最后到数据通信。因此，以数据为中心的DDS
协议得到了关注。
2 以数据为中心的
通信中间件DDS
2.1 中间件的概念
首先，需要先理解什么是中间件？分布式系统中，中间件是位于操作系统和用户应用程序之间的软件层，它将操作系统提供的资源进行抽象和封装，为应用程序提供各种各样的高级的服务和功能，比如通信或数据共享。中间件的存在简化了应用程序开发者的工作，这使他们能够将注意力放在应用程序本身上，而不必在不同应用程序之间或不同系统之间的数据传输上花太多精力。
2.2 DDS 概述
从历史的起源来看的话， DDS最早应用于美国海军，用于解决舰船复杂网络环境中大量软件升级的兼容性问题，已经成为美国国防部的强制标准。2003年，DDS被OMG组织接受，并发布了专门为实时系统设计的数据分发/订阅标准。DDS已经广泛应用于国防、民航、工业控制等领域，成为分布式实时系统中数据发布/订阅的标准解决方案。其主要的协议OMG
协议规范族如下：
2.3 DDS 的特点
2.3.1 以数据为中心
DDS号称是唯一的以数据为中心的通信中间件，OMG把以数据为中心这个特征看成一个重要的特点。DDS把系统的数据按照主题组织在“全局数据空间”，不同的应用通过发布者以及订阅者去读写全局数据空间的数据，值得注意的是这个全局数据空间只是一个逻辑上的概念，不是一个物理上的存储空间，实际的数据是分布式的存储在各个应用上。如下图。
2.3.2 丰富的QOS
QoS即服务质量，DDS在协议层面提供多种通信服务需求的抽象，提供QoS配置来细粒度的控制通信行为，使QoS可以极大的简化通信程序的设计，无需应用再重复实现所需的服务质量。DDS标准规范即提供22种QoS。
如果希望某个Topic能够周期更新，可以设置DEADLINE属性。在数据的发布方设置DEADLINE，这意味着应用程序必须以小于DEADLINE的周期去更新Topic；而在数据的订阅方设置DEADLINE，这意味着数据的发布方必须以小于DEADLINE的周期去发布Topic。
通过设置LIFESPAN，可以使DataWriter写入的每个数据样本都有一个关联的“到期时间”，超过该时间后，该数据样本不再传送给任何应用程序，并且这些数据将从DataReader缓存中清除。
设置HISTORY属性可以让DataWriter保存并发送旧的采样数据，新的DDS节点如果订阅了相关的Topic，它不仅能够接收到数据的当前值，也能收到一部分历史值，从而了解数据近期的变化趋势。
为DataWriter设置RELIABILITY属性，可以使数据实现“可靠”的传输，当出现通信错误导致数据采样没有被接收到时，DataWriter会持续重传，直到所有数据被正确接收。
2.4 常用的DDS 中间件组件
3 FastDDS 源码分析
3.1 源码结构
Plain
Text
目录
/文件 核心功能
src/ 核心源码目录，包含所有模块实现
├─ cpp/ C++ 核心代码（Fast DDS 基于 C++ 11 及以上标准）
│ ├─ dds/ DDS 规范适配层：实现 DDS 核心实体（DomainParticipant、Publisher
等）
│ ├─ rtps/ RTPS 协议核心层：实现 RTPS 协议的参与者、写入者、读取者、发现机制等
│ ├─ transport/ 传输层：实现 UDPv4、UDPv6、TCP、共享内存等传输方式
│ ├─ security/ 安全模块：实现 DDS-Security 规范（认证、加密、访问控制）
│ ├─ utils/ 工具类：内存池、日志、时间管理、UUID 生成等
│ ├─ event/ 事件驱动模块：处理超时重传、心跳发送、发现消息等异步事件
│ ├─ types/ 数据类型模块：动态类型、IDL 类型支持、序列化/反序列化（依赖
Fast CDR）
│ └─ qos/ QoS 管理模块：实现 DDS 规范中的 QoS 策略（可靠性、持久性等）
thirdparty/ 第三方依赖库：Fast CDR（序列化）、asio（网络）、OpenSSL（安全）等
examples/ 示例代码：简单发布订阅、QoS 配置、安全通信等
cmake/ CMake 配置文件：编译选项、平台适配、依赖管理
docs/ 文档：API 手册、用户指南、源码注释说明 |
3.2 核心工作流程
Fast DDS 的核心工作流程围绕数据发布与订阅展开，体现了各模块的协同作用。整个流程可以分为创建初始化、发现匹配、数据传输和可靠性保障四个阶段。
a.实体创建：从DomainParticipant→Publisher→DataWriter→RTPSWriter的层次化创建
b.序列化：通过TypeSupport将用户数据转为CDR格式
c.历史缓存：数据样本首先存入WriterHistory，按QoS策略管理生命周期
d.可靠传输：StatefulWriter维护ACK/NACK机制，确保数据可靠到达
a.自动发现：通过SEDP自动发现匹配的DataWriter，创建代理对象
b.反序列化：将接收的CDR数据还原为用户数据类型
c.回调通知：通过on_data_available回调通知应用程序
d.历史管理：ReaderHistory缓存数据，支持read/take两种读取模式
3.3 核心模块分析
3.3.1 RTPS 协议核心模块（src/cpp/rtps/）
RTPS（Real-Time Publish-Subscribe Protocol）是 OMG 定义的实时发布订阅协议，是
DDS 的底层通信标准。Fast DDS 的 RTPS 模块是整个框架的“引擎”，负责端点发现、数据传输、可靠性保障。
- RTPS 核心实体与关系
- RTPS 层定义了多个核心实体，对应源码中的关键类，其关系如下：
- RTPSParticipant：RTPS 层的“参与者”，对应 DDS 层的 DomainParticipant，是所有
RTPS 实体的容器，负责管理端点、发现机制、传输通道。
- RTPSWriter：RTPS 层的“写入者”，对应 DDS 层的 DataWriter，负责发送数据样本。分为两种类型：
- StatelessWriter：无状态写入者，不维护接收方状态（如 UDP 多播的“尽力交付”），适合实时性要求高、允许丢包的场景。
- StatefulWriter：有状态写入者，维护接收方的确认状态（通过 ACK/NACK 机制），保障可靠性（如重传丢失的样本）。
- RTPSReader：RTPS 层的“读取者”，对应 DDS 层的 DataReader，负责接收数据样本。同样分为两种类型：
- StatelessReader：无状态读取者，不向写入者反馈接收状态，仅被动接收。
- StatefulReader：有状态读取者，向写入者发送 ACK/NACK 消息，告知已接收的样本序号，触发重传。
- Endpoint：RTPS 端点的抽象基类，RTPSWriter 和 RTPSReader 均继承自
Endpoint，包含端点的唯一标识（GUID）、QoS 策略、历史缓存等信息。
- GUID：全局唯一标识符（Global Unique Identifier），用于标识 RTPS
参与者和端点（格式：Prefix + EntityId），是发现机制和数据路由的核心。
3.3.2 发现机制（SPDP + SEDP）
DDS 的发现机制是动态发现的核心，无需预先配置网络地址即可自动发现通信端点。Fast DDS 通过
SPDP 和 SEDP 两个协议实现分层发现机制：
a.分层发现：SPDP 发现参与者 → SEDP 发现端点
b.多播+单播结合：SPDP 使用多播，SEDP 使用单播
c.周期性维护：定期发送心跳，检测离线状态
d.完全自动化：无需人工配置，支持网络拓扑动态变化
3.3.3 历史缓存（History）模块
历史缓存模块是 DDS 可靠性、持久性和数据可追溯性的基石，负责管理数据样本的生命周期，支撑重传、持久化和
QoS 策略的实现。
3.3.4 QoS 管理模块（src/cpp/qos/）
QoS（Quality of Service，服务质量）是 DDS 的核心特性，允许用户通过配置策略控制通信的可靠性、持久性、延迟等行为。Fast
DDS 实现了 DDS 规范中的所有 QoS 策略，源码位于 src/cpp/qos/。
4 总结和展望
4.1 总结
通过上述分析，我们可以看到，DDS（尤其是以 Fast DDS 为代表的开源实现）凭借其 以数据为中心、丰富的QoS策略和完全解耦的动态发现
等核心特性，正成为新一代汽车电子电气架构（特别是面向服务的SOA架构和区域导向的Zonal架构）中通信中间件的关键技术选择。
1.匹配架构演进趋势：DDS的发布-订阅模型和全局数据空间理念，完美契合了汽车从“信号导向”到“服务/数据导向”的通信范式转变，满足了中央计算、跨域融合和软件定义汽车对高带宽、低延迟、灵活通信的需求。
2.提供确定性的服务质量：其内置的20多种QoS策略（如可靠性、持久性、截止时间、延迟预算等），使开发人员能够通过配置而非编码，精细控制数据的传输行为，为实现功能安全、信息安全和实时性要求提供了坚实基础。
3.实现彻底的解耦与动态组网：基于RTPS协议的SPDP/SEDP发现机制，使得网络中的参与者、发布者与订阅者能够自动发现彼此，无需硬编码地址。这极大地提升了系统的可扩展性、可维护性和容错能力，支持软件组件的即插即用与OTA升级。
4.强大的开源生态支撑：以 eProsima Fast DDS 为代表的成熟开源实现，不仅性能优异、功能完整，还拥有活跃的社区和商业支持。它作为ROS
2的默认中间件，在机器人领域得到了充分验证，这为其在技术栈相似的自动驾驶领域铺平了道路。同时，它也能无缝集成到
AUTOSAR Adaptive 标准框架中，满足汽车行业对标准化和供应链的要求。
4.2 挑战
-
功能安全（FuSa）认证：将 DDS（特别是其开源实现）按照 ISO 26262 等标准进行高级别的功能安全认证，是其在安全相关控制器（如自动驾驶域、底盘域）中广泛应用的前提。这需要持续投入，建立完整的开发流程和安全案例。
- 资源占用优化：针对资源受限的嵌入式ECU，需要进一步优化 DDS 协议栈的内存占用和CPU开销，提供更极致的“微”版本。
- 时间敏感网络（TSN）集成：为了满足整车层面严格的同步和确定性延迟需求，DDS需要与汽车以太网TSN标准进行更深度的协同，例如利用TSN的调度和门控机制来保障高优先级DDS流的传输。
- 工具链与生态完善：提供更强大的可视化监控、性能分析、数据记录与回放、系统配置等工具，降低开发、调试和运维的复杂度，是提升工程师效率、推动DDS普及的关键。
4.3 结语
总而言之，在软件定义汽车和中央集中式电子电气架构的时代浪潮下，DDS 提供了一种面向未来、高度灵活且功能强大的数据通信解决方案。它不仅是连接车内海量传感器、高性能计算单元和区域控制器的“数据总线”，更是构建松散耦合、可动态重构的智能汽车软件体系的“粘合剂”。随着开源社区的持续发力、行业标准的不断完善以及与汽车专属技术（如AUTOSAR,
TSN）的深度融合，DDS 有望在汽车产业这场深刻的智能化变革中，扮演越来越核心的角色。 | 
订阅
