前言：随着汽车EEA（电子电气架构）从分布式架构向域控制器和中央计算架构演进，传统的 CAN/LIN 总线在带宽上已无法满足需求，汽车以太网应运而生。而在汽车以太网的众多应用层协议中，(Data Distribution Service for Real-Time Systems)正受到越来越多的关注。本文将对DDS做一些介绍。
目录
一、EEA架构的演进
二、通信方式的比较
三、中间件
四、DDS核心机制
4.1 全局数据空间
4.2 底层传输优化（RTPS协议）
4.3 极其精细的QoS（Quality of Service）
五、DDS面临的挑战
5.1 数据安全性
5.2 功能安全（FuSa）认证
5.3 资源占用优化
5.4 工具链完善
一、EEA架构的演进
DDS是实现软件定义汽车 (SDV)和SOA (面向服务架构)的关键技术之一，它符合不断演进的EEA架构需求。
1）分布式EEA：
2）域控EEA：
3）中央集中式EEA：
二、通信方式的比较
随着EEA的演进，通信需求从面向信号(CAN) -> 面向服务(SOME/IP) -> 面向数据(DDS)通信慢慢演进。以数据为中心的DDS协议得到了汽车行业的关注。
| 维度 | CAN (Controller Area Network) | SOME/IP (Scalable service-Oriented MiddlewarE over IP) | DDS (Data Distribution Service) |
|---|---|---|---|
| 架构 | 面向消息/信号 | 面向服务 | 以数据为中心 |
| 通信模型 | 广播/多播 (显式或隐式) | Request/Response (RPC) Publish/Subscribe (Notify) | 发布/订阅模式 |
| 传输层协议 | 无 (物理层/数据链路层) | TCP(用于大数据/请求响应) UDP(用于事件通知) | 主要是UDP(支持共享内存，TCP较少用) |
| 网络层协议 | CAN Frame (无IP地址) | IP(基于以太网) | IP(基于以太网，也支持共享内存) |
| 带宽/速度 | 低 (传统CAN 1Mbps, CAN FD 5Mbps) | 高 (以太网 100M/1G/10G) | 高 (以太网 100M/1G/10G) |
| 发现机制 | 静态配置 (ID固定，无需发现) | SD (Service Discovery) (需配置Service ID，支持动态发现) | 内置发现机制 (SPDP/DPDP，自动发现Topic/节点) |
| QoS (服务质量) | 依靠ID仲裁决定优先级 | 依靠底层网络 + 配置 (如可靠性Reliability区分TCP/UDP) | 极其丰富 (22+种QoS策略) |
| 实时性 | 硬实时 (确定性的低延迟) | 软实时 (受以太网CSMA/CD的影响) | 可调的实时/硬实时 (通过QoS配置可达到确定性) |
| 应用场景 | 车身、底盘控制 (低带宽、控制信号) | ADAS、信息娱乐、车联网 (需要方法调用、逻辑交互) | 自动驾驶、机器人、军工 (海量高频数据、数据分发) |
| 系统开销 | 极低 | 中等 (需序列化/反序列化) | 较高 (复杂的发现机制和QoS处理) |
| 拓扑结构 | 总线型 | 星型网络 | 总线型/星型/网状 (灵活) |
三、中间件
DDS本质实际是一个通信中间件，本节首先介绍什么是中间件。
中间件是介于操作系统与用户/应用程序之间的一个软件层，它将操作系统提供的资源进行抽象与封装，为上层（用户/应用程序）提供各种各样的高级服务和功能，比如通信或数据共享等。中间件的存在极大地简化了应用程序开发的工作，这使得应用开发者能够将注意力放在应用程序（业务逻辑、算法实现等）本身上，而不必花很多时间和精力去关心不同应用程序之间或不同操作系统之间的数据传输与交互。
四、DDS核心机制
4.1 全局数据空间
DDS 在整个车载网络中构建了一个虚拟的“全局数据空间”。
- 去中心化：DDS 不需要像 MQTT 那样的 Broker（代理服务器），不需要中央节点来管理数据据传输。所有的 ECU、传感器、域控制器都是对等的节点。
- 自动发现机制：当一个新的节点（比如一个新的传感器）接入到网络，DDS 的发现机制（SPDP/SEDP）会自动通知网络中其他所有节点：“这里来了一个新的数据源，发布‘点云数据’，谁需要就举手？”
4.2 底层传输优化（RTPS协议）
DDS 的底层传输protocol 是RTPS (Real-Time Publish-Subscribe)。
- 基于 UDP：汽车功能(特别是自动驾驶相关)对延迟极其敏感。DDS 默认使用UDP而非 TCP，因为 TCP 的握手和确认机制会带来不可接受的延迟。
- 直接通信：数据包直接从发布者 IP发送到订阅者 IP，中间不经过任何路由转发，极大降低了传输延迟。
4.3 极其精细的QoS（Quality of Service）
这是 DDS 区别于 SOME/IP 和 MQTT 的杀手锏。DDS 定义了20 多种QoS 策略，让用户可以精确控制通信的方方面面，以满足不同场景（如实时控制、文件传输、状态监控等）的需求。
- Reliability（可靠性）：
- Best Effort： 允许丢包，追求最快速度（适合传感器数据流）。
- Reliable：保证数据一定送达，自动重传（适合指令控制）。
- History（历史记录）：
- 决定如果接收端跟不上发送端的速度，或者接收端刚上线时，发送端要保存多少历史数据。
- Keep Last：只保留最新的 N 个样本。
- Keep All：保留所有样本（适合文件传输或日志）。
- Durability（持久性）：
- Volatile：只有在线时才能收到数据（默认）。
- Transient Local：新加入的订阅者，可以立即收到发布者当前状态（例如：地图数据，新节点加入时立马拿到最新地图，而不是等下一个更新周期）。
- Deadline（截止时间）：
- 规定数据更新的最大间隔。如果发布者超过这个时间没更新，DDS 会通知订阅者“数据过期了”（非常适合用于检测传感器是否断开连接）。
- Liveliness（活跃度）：
- 检测发布者是否还“活着”。如果一个节点死机了，其他节点可以通过该策略迅速知悉。
五、DDS面临的挑战
5.1 数据安全性
DDS本身不提供加密和认证机制，需要依赖TLS/SSL等安全协议或应用层安全措施来保障数据传输的安全性。
5.2 功能安全（FuSa）认证
将 DDS按照ISO 26262等标准进行高级别的功能安全认证，是其在安全相关控制器（如自动驾驶域、底盘域）中广泛应用的前提。这需要持续投入，建立完整的开发流程和安全机制。
5.3 资源占用优化
DDS在数据处理和传输过程中需要消耗大量的CPU资源，针对资源受限的嵌入式ECU，需要进一步优化 DDS 协议栈的内存占用和CPU开销，提供更极致的“微”版本。
5.4 工具链完善
就作者的经验而言，做任何项目，工具都是最基本的保障，需要做到工具先行，否则开发进度受很大影响。DDS的开发工具链还不够完善，缺乏直观的调试和监控工具，增加了系统开发调试的难度。
写在最后：目前常用的DDS有Fast DDS、Cyclone DDS、Open DDS等，感兴趣的童鞋可针对某个DDS继续做一些深入了解。
