3、DDS深度解析：全局数据空间、QoS策略与分区主题

各位同学，今天我们聊DDS。说实话，这个中间件在自动驾驶圈子里，已经快成标配了。我最早接触DDS是在2018年做某个量产项目的时候，当时团队还在纠结要不要用，结果一用就回不去了。为什么？因为它解决了一个核心问题——数据怎么在几十个节点之间可靠、实时地流转。

好，我们直接进入正题。今天讲三个核心概念：全局数据空间、QoS策略、分区与主题。这三个东西，你搞懂了，DDS就算入门了。

3.1 全局数据空间：所有节点共享的“黑板”

先说说全局数据空间。这个概念，说白了就是DDS给你画了一个虚拟的“黑板”。所有节点——不管是感知模块、规划模块还是控制模块——都在这个黑板上读写数据。你不需要关心数据在哪个进程、哪台机器上，你只需要知道：我往这个主题写数据，订阅者就能拿到。

我个人习惯把全局数据空间理解成一个分布式共享内存。每个节点发布数据时，DDS中间件会自动把数据复制到所有感兴趣的订阅者那里。这个过程对开发者是透明的。

我在项目中遇到过一个问题：某个感知节点发布了障碍物列表，但规划节点死活收不到。排查了半天，发现是发现协议的超时时间设置得太短，导致节点没有完成互相发现。嗯，这里要注意——发现协议的参数，别乱改。

3.2 QoS策略：让数据通信“懂规矩”

QoS，全称Quality of Service，服务质量。你想想看，自动驾驶里有些数据丢了就丢了（比如某个时刻的摄像头画面），但有些数据绝对不能丢（比如刹车指令）。DDS的QoS策略就是用来干这个的——给不同的数据流制定不同的通信规则。

我重点讲三个最常用的QoS策略：可靠性、历史记录、时效性。

3.2.1 可靠性（Reliability）

可靠性策略有两种模式：RELIABLE（可靠）和BEST_EFFORT（尽力而为）。

• RELIABLE：保证每个样本都被送达。如果丢包，会自动重传。适合控制指令、紧急消息。
• BEST_EFFORT：尽力发送，不保证送达。适合传感器数据、视频流。

我曾经在项目中犯过一个错误：把所有主题都设成RELIABLE。结果呢？网络稍微一波动，大量重传导致带宽爆炸，整个系统延迟飙升。后来我学乖了——传感器数据用BEST_EFFORT，控制指令用RELIABLE。

3.2.2 历史记录（History）

历史记录策略控制的是：DDS要保留多少历史数据给新加入的订阅者。

有两种模式：

• KEEP_LAST：只保留最近N个样本。N由你指定。
• KEEP_ALL：保留所有样本，直到资源耗尽。

我个人习惯：对于轨迹规划这类需要历史上下文的数据，用KEEP_LAST，深度设成5-10。对于传感器数据，直接用KEEP_LAST深度=1，因为只看最新帧就够了。

场景	推荐策略	深度
控制指令	KEEP_LAST	1
轨迹规划	KEEP_LAST	5-10
传感器数据	KEEP_LAST	1
日志记录	KEEP_ALL	不限

3.2.3 时效性（Lifespan）

时效性策略，说白了就是给数据设一个过期时间。超过这个时间还没被消费，数据就自动丢弃。

为什么会需要这个？你想想看，自动驾驶里有些数据是有时效性的。比如某个时刻的障碍物位置，过了100ms就没意义了。如果订阅者处理不过来，堆积了大量过期数据，反而会干扰决策。

我建议：传感器数据设时效性为50-100ms，控制指令设成无限。为什么控制指令设无限？因为控制指令必须被处理，哪怕延迟了也比丢掉好。

3.3 分区与主题：数据组织的“文件夹”

主题（Topic）是DDS里最基本的数据通道概念。每个主题有一个名字，发布者和订阅者通过主题名匹配。但问题来了——如果系统里有100个主题，怎么管理？

这时候就需要分区（Partition）。分区可以理解成主题的命名空间。同一个主题名，在不同分区里是隔离的。

举个例子：

分区: "sensor_front"
  主题: "camera_image"
  主题: "lidar_pointcloud"

分区: "sensor_rear"
  主题: "camera_image"
  主题: "lidar_pointcloud"

你看，前后摄像头都用同一个主题名"camera_image"，但因为分区不同，数据不会混淆。这个设计在实车上特别有用——不同传感器组的数据天然隔离。

我在项目中遇到过一个问题：某个模块订阅了"camera_image"主题，结果收到了前后两个摄像头的混合数据。排查后发现，是分区配置写错了，两个分区被合并了。嗯，这里要注意——分区名要严格区分，别偷懒用默认分区。

3.4 实战建议：如何配置QoS

最后，我给大家一个实战配置模板。这是我个人在多个项目中总结出来的经验：

// 传感器数据（高频、大体积）
QoS:
  Reliability: BEST_EFFORT
  History: KEEP_LAST
  Depth: 1
  Lifespan: 100ms

// 控制指令（低频、关键）
QoS:
  Reliability: RELIABLE
  History: KEEP_LAST
  Depth: 1
  Lifespan: INFINITE

// 轨迹规划（中等频率、需要上下文）
QoS:
  Reliability: RELIABLE
  History: KEEP_LAST
  Depth: 10
  Lifespan: 500ms

你想想看，如果所有数据都用同一套QoS配置，要么浪费带宽，要么丢关键数据。所以，针对不同数据类型，定制不同的QoS策略，这是DDS调优的核心。

好，今天就讲到这里。下一章我们聊DDS的发现协议和动态节点管理——说白了就是节点之间怎么互相找到的。到时候我会分享一个我在实车上遇到的“幽灵节点”问题，挺有意思的。