第4章：DDS协议详解

好，咱们今天聊聊DDS。说实话，我在智能座舱项目里第一次接触DDS时，心里是有点抵触的——又学一个新协议？但用下来发现，这玩意儿确实有它的独到之处。

4.1 DDS的核心概念

DDS，全称Data Distribution Service，数据分发服务。它不像SOME/IP那样走客户端-服务器模式，而是走发布-订阅模式。说白了，就是谁有话想说就说，谁想听就听，中间不需要一个中心节点来调度。

4.1.1 域（Domain）

域，你可以理解成一个独立的通信空间。同一个域里的节点才能互相通信。不同域之间是隔离的，就像WiFi的不同信道。

我在项目中遇到过一个问题：测试车和量产车用了同一个域ID，结果测试数据跑到了量产车上。嗯，从那以后我定了个规矩——每个项目必须分配独立的域ID，测试环境再加一个偏移量。

4.1.2 主题（Topic）

主题是DDS通信的基本单元。每个主题有一个名字，还有对应的数据类型。发布者往主题上写数据，订阅者从主题上读数据。

举个例子：

// 定义主题数据类型
struct VehicleSpeed {
    float speed;        // km/h
    uint64 timestamp;   // 微秒级时间戳
    uint8 source;       // 数据来源：0=ESP, 1=GPS
};

// 创建主题
Topic<VehicleSpeed> speedTopic("Vehicle/Speed");

主题命名我建议用层级结构，比如"Vehicle/Speed"、"Vehicle/SteeringAngle"。这样在调试时一眼就能看出数据归属。

4.1.3 数据写入者/读取者（DataWriter/DataReader）

DataWriter是发布者的代言人，DataReader是订阅者的代言人。它们负责实际的数据收发。

我习惯把DataWriter想象成一个邮递员——你把信交给他，他负责送到。至于怎么送、什么时候送，那是QoS策略的事。

// 创建DataWriter
DataWriter<VehicleSpeed> writer(speedTopic);

// 写入数据
VehicleSpeed data;
data.speed = 60.5;
data.timestamp = getCurrentTimestamp();
data.source = 0;
writer.write(data);

4.2 QoS策略

QoS是DDS的灵魂。没有QoS的DDS，就像没有调料的菜——能吃，但不好吃。

常用的QoS策略有这些：

QoS策略	作用	我常用的场景
RELIABILITY	可靠性：RELIABLE（可靠）或BEST_EFFORT（尽力）	控制指令用RELIABLE，传感器数据用BEST_EFFORT
DURABILITY	持久性：新加入的订阅者能否收到历史数据	车辆状态用TRANSIENT_LOCAL，实时数据用VOLATILE
DEADLINE	数据更新的最大间隔	安全相关数据必须设置，比如刹车信号
LIVELINESS	节点存活检测	所有节点都设，方便故障诊断

4.3 DDS与SOME/IP的对比

这两个协议经常被拿来比较。说实话，它们不是替代关系，而是互补关系。我一般这样选型：

维度	DDS	SOME/IP
通信模式	发布-订阅（去中心化）	客户端-服务器（可中心化）
实时性	强（微秒级）	中等（毫秒级）
QoS支持	丰富（20+种策略）	有限（主要靠超时重试）
资源消耗	较高（内存、CPU）	较低（适合MCU）
适用场景	传感器融合、ADAS、座舱	诊断、配置、远程调用

我个人的经验是：

• 高频数据流（比如摄像头、激光雷达）→ 用DDS
• 偶发请求（比如获取车辆VIN码）→ 用SOME/IP
• 控制指令（比如刹车、转向）→ 两者皆可，但DDS的QoS更灵活

你想想看，如果让SOME/IP去传每秒30帧的图像数据，光是序列化/反序列化的开销就够呛。反过来，如果让DDS去做一个简单的"获取电池电压"的请求，又有点大材小用。

嗯，DDS这块内容不少，但核心就是这几个概念。你先把域、主题、DataWriter/DataReader搞明白，再理解QoS策略，最后对比SOME/IP找到适用场景。这样在实际项目中就不会抓瞎了。