3. DDS核心概念
在车载DDS服务中间件中，理解其核心概念是掌握后续工程实践的基础。DDS（Data Distribution Service）采用以数据为中心的发布/订阅模型，其核心思想是：数据生产者与数据消费者之间不直接建立连接，而是通过一个逻辑上的“全局数据空间”进行解耦交互。生产者将数据发布到某个主题上，消费者订阅该主题即可接收数据，双方无需知道对方的存在、地址或数量。这种模型天然适合车载系统中传感器、控制器、执行器之间动态、多对多、实时性要求高的通信场景。
一、发布/订阅模型：以数据为中心的通信范式
发布/订阅模型是DDS的通信基石。与传统的请求/响应模型不同，发布/订阅模型中的参与者分为两类：发布者（Publisher）和订阅者（Subscriber）。发布者负责将数据写入全局数据空间，订阅者负责从全局数据空间中读取感兴趣的数据。DDS中间件负责匹配发布与订阅关系，并完成数据的自动分发。
这种模型的关键优势在于时间解耦、空间解耦和同步解耦。时间解耦意味着发布者和订阅者不必同时在线；空间解耦意味着双方不需要知道对方的网络地址；同步解耦意味着发布者不必等待订阅者确认即可继续发布。在车载环境中，这意味着一个雷达数据发布者可以持续发布数据，而多个订阅者（如感知融合、显示模块、记录模块）可以按需订阅，互不阻塞。
核心要点：DDS的发布/订阅不是简单的消息队列，而是以数据为中心的“状态传播”。中间件只关心“当前最新数据是什么”，而不是“消息是否被消费”。这使得DDS非常适合周期性强、实时性高的车载数据流。
二、域、主题、数据写入者与数据读取者
DDS通过几个关键抽象来组织通信：域（Domain）、主题（Topic）、数据写入者（DataWriter）和数据读取者（DataReader）。它们之间的关系可以用下面的SVG图来直观理解。
域（Domain）是DDS中最大的隔离单位。每个域拥有独立的全局数据空间，不同域之间的参与者完全隔离，互不可见。在车载系统中，通常会按功能划分域，例如动力域、感知域、座舱域，避免不同功能域之间的数据干扰。
主题（Topic）是数据发布的逻辑通道，由“主题名称”和“数据类型”共同定义。例如，主题名称为“/sensor/lidar”，数据类型为“LidarScan”。只有主题名称和数据类型完全匹配的发布者和订阅者才能建立通信。主题是DDS中数据分类和路由的核心依据。
数据写入者（DataWriter）是发布者内部的实际写入对象，负责将具体数据样本写入到某个主题上。一个发布者可以创建多个DataWriter，每个DataWriter绑定一个主题，并携带独立的QoS配置。DataWriter是应用层调用write()接口的直接对象。
数据读取者（DataReader）是订阅者内部的实际读取对象，负责从某个主题上接收数据样本。一个订阅者可以创建多个DataReader，每个DataReader订阅一个主题，并请求特定的QoS。DataReader通过监听器或条件变量通知应用层有新数据到达。
三、服务质量策略（QoS）的基本含义
QoS是DDS区别于普通消息中间件的核心特性。它允许开发者为每个DataWriter和DataReader配置一系列通信行为参数，中间件会根据发布端和订阅端的QoS请求进行匹配，只有兼容的QoS才能建立通信。常见的QoS策略包括：
| QoS策略 | 含义 | 车载典型取值 |
|---|---|---|
| RELIABILITY | 可靠性：BEST_EFFORT或RELIABLE | 感知数据用BEST_EFFORT，控制指令用RELIABLE |
| DURABILITY | 持久性：VOLATILE或TRANSIENT_LOCAL | 静态配置用TRANSIENT_LOCAL，实时流用VOLATILE |
| DEADLINE | 时限：期望的最大数据间隔 | 雷达数据20ms，CAN信号10ms |
| HISTORY | 历史：KEEP_LAST或KEEP_ALL | KEEP_LAST depth=1，只保留最新值 |
| PARTITION | 分区：逻辑隔离同一域内的通信 | 按功能分区，如“perception”、“control” |
提示：QoS匹配是双向的。发布端提供QoS，订阅端请求QoS，中间件检查两者是否兼容。例如，发布端为BEST_EFFORT，订阅端请求RELIABLE，则无法匹配，通信不会建立。因此，在车载DDS工程中，QoS配置必须作为接口契约的一部分进行管理。
四、案例场景：车载雷达数据分发
假设一辆智能驾驶车辆上有一个激光雷达，周期为20ms发布一帧点云数据。感知融合模块、可视化模块和行车记录模块都需要使用该数据。采用DDS后，系统设计如下：
- 创建一个域，域ID为0，代表感知域。
- 定义一个主题“/sensor/lidar”，数据类型为“LidarScan”。
- 激光雷达驱动作为发布者，创建一个DataWriter，绑定该主题，QoS配置为：RELIABILITY=BEST_EFFORT，HISTORY=KEEP_LAST(1)，DEADLINE=20ms。
- 感知融合模块作为订阅者，创建一个DataReader，订阅该主题，请求QoS：RELIABILITY=BEST_EFFORT，HISTORY=KEEP_LAST(1)。
- 可视化模块同样创建DataReader，但请求HISTORY=KEEP_LAST(5)，以便绘制连续帧。
- 行车记录模块请求DURABILITY=TRANSIENT_LOCAL，以便在启动后能获取最近一帧数据。
中间件会自动匹配发布者和订阅者，并根据各自的QoS进行数据分发。发布者无需知道有多少订阅者，也无需等待确认，从而保证了20ms周期的稳定性。
// 伪代码示例：创建DataWriter并配置QoS
DataWriterQos dw_qos;
dw_qos.reliability.kind = BEST_EFFORT_RELIABILITY_QOS;
dw_qos.history.kind = KEEP_LAST_HISTORY_QOS;
dw_qos.history.depth = 1;
dw_qos.deadline.period = {0, 20000000}; // 20ms
DataWriter* writer = publisher->create_datawriter(topic, dw_qos);
writer->write(&lidar_scan);
五、常见误区与复盘
误区一：认为DDS的发布/订阅等同于消息队列。消息队列通常有明确的队列深度和消费确认机制，而DDS以数据为中心，强调“最新状态”的传播。使用DDS时，应关注数据样本的生命周期和QoS，而不是消息的入队出队。
误区二：忽略QoS匹配导致通信失败。很多初学者只配置了主题名称和数据类型，却忽略了QoS兼容性。例如，发布端使用RELIABLE，订阅端使用BEST_EFFORT，虽然可以匹配，但订阅端无法获得可靠性保证；反之则无法建立通信。务必在接口设计阶段明确QoS契约。
误区三：在同一个域中混用不同功能的数据。域是隔离单位，不同功能的数据应放在不同域中，避免不必要的发现流量和QoS冲突。例如，动力控制域和娱乐域应分开。
复盘来看，掌握DDS核心概念的关键在于理解“以数据为中心”的思想：域提供隔离边界，主题定义数据通道，DataWriter和DataReader是实际读写端点，QoS则定义了通信行为的契约。只有将这五个概念融会贯通，才能在车载DDS工程中设计出高可靠、低延迟、可扩展的通信架构。