2. DDS基础
DDS（Data Distribution Service）是面向实时分布式系统的数据总线标准，它把“数据”作为一等公民：应用不再关心对端地址和连接过程，而是围绕主题（Topic）发布或订阅数据。理解 DDS 的发布订阅模型、域与分区、QoS、IDL 类型以及发现机制，是后续把 DDS 与 SOME/IP 网关做语义映射的基础。
一、发布订阅模型：以数据为中心的通信
DDS 采用以数据为中心（Data-Centric）的发布订阅模型。参与者分为 DataWriter（发布端）和 DataReader（订阅端），二者通过 Topic 匹配。Topic 由“名称 + 数据类型”唯一确定，只有名称和类型都一致，读写端才可能建立关联。
- DomainParticipant：进程在某个域中的入口，管理 Publisher、Subscriber、Topic。
- Publisher / DataWriter：发布端，负责将样本写入全局数据空间。
- Subscriber / DataReader：订阅端，从数据空间接收匹配的样本。
- Topic：数据名称与类型的绑定，是匹配的核心键。
与请求-响应不同，DDS 的发布者不需要知道订阅者是谁，订阅者也不需要主动拉取。数据在“全局数据空间”中按 Topic 流动，天然支持一对多、多对多和多播式分发，非常适合传感器流、状态广播和实时控制。
二、域与分区：逻辑隔离的两级手段
域（Domain）是最强的隔离边界。每个 Domain 用 DomainId 标识，不同域中的参与者默认完全不可见，即使 Topic 名称相同也不会匹配。工程中常用域来隔离动力、座舱、诊断等不同安全等级或不同车型的数据流。
分区（Partition）是域内的进一步逻辑划分。发布端和订阅端通过分区字符串（如 /front、/rear）进行匹配，只有分区有交集时才会通信。分区适合在同一域内按位置、功能或租户做轻量隔离，而不必新建域。
三、QoS策略：DDS的“通信契约”
QoS 是 DDS 最核心的工程能力。发布端和订阅端各自声明 QoS，只有请求-提供（Requested-Offered）兼容时才会匹配。常见策略如下：
| QoS 策略 | 作用 | 典型取值 | 工程含义 |
|---|---|---|---|
| RELIABILITY | 可靠性 | BEST_EFFORT / RELIABLE | 周期传感器可用 BEST_EFFORT；控制指令必须 RELIABLE |
| DURABILITY | 历史数据保留 | VOLATILE / TRANSIENT_LOCAL | 晚加入的订阅者能否收到最后一条状态 |
| HISTORY | 历史缓存深度 | KEEP_LAST(n) / KEEP_ALL | 决定缓存多少样本，影响内存与补发能力 |
| DEADLINE | 更新周期约束 | 如 100ms | 超时触发回调，用于检测数据源失联 |
| LIVELINESS | 存活检测 | AUTOMATIC / MANUAL | 判断发布者是否仍然在线 |
| OWNERSHIP | 多发布者仲裁 | SHARED / EXCLUSIVE | 冗余发布时只取最高优先级 |
QoS 不匹配是 DDS 集成中最常见的“静默失败”：两端都启动成功，但数据就是不通。排障时应优先检查 RELIABILITY、DURABILITY 和 Partition 是否兼容。
四、数据类型与IDL：Topic的契约
DDS 使用 IDL（Interface Definition Language）定义 Topic 的数据类型，再由工具生成各语言的类型支持代码。IDL 结构一旦发布，就相当于接口契约，修改字段需谨慎，避免破坏兼容性。
struct SpeedMsg {
long vehicle_id;
float speed_kph;
double timestamp;
string source;
};
@topic
struct GearMsg {
long vehicle_id;
octet gear;
};IDL 支持结构体、枚举、序列、数组和嵌套类型。工程中应遵循“只增不改”的演进原则：新增字段使用可选或带默认值，避免删除或改变已有字段类型，否则新旧节点可能无法互通。
五、发现机制：SPDP与SEDP
DDS 的自动发现分为两步：SPDP（Simple Participant Discovery Protocol）负责在域内广播/组播参与者信息，让各节点知道彼此存在；SEDP（Simple Endpoint Discovery Protocol）在已发现的参与者之间交换 DataWriter/DataReader 的端点信息与 QoS，完成匹配。
- Participant 启动，周期发送 SPDP 通告。
- 收到对方 SPDP 后，建立单播通道。
- 通过 SEDP 交换 Topic、类型和 QoS。
- QoS 兼容则建立关联，数据开始流动。
六、典型应用场景与复盘
DDS 常见于自动驾驶域控、机器人、航空电子、工业实时控制和车路协同等场景。其优势是松耦合、高实时、QoS 可精细控制；代价是配置复杂、发现流量和 QoS 匹配需要经验。
一个典型误区是：把 DDS 当成“带 Topic 的 UDP”。实际上，DDS 的匹配是名称、类型、QoS、分区四者共同作用的结果。复盘时建议按以下清单逐项核对：
- 两端是否在同一 DomainId？
- Topic 名称与数据类型是否完全一致？
- Partition 是否有交集？
- RELIABILITY、DURABILITY 是否请求-提供兼容？
- 网络是否允许组播，或是否配置了 Initial Peers？
- IDL 版本是否一致，字段是否兼容？
掌握这些基础后，才能把 DDS 的 Topic 与 SOME/IP 的服务/事件做正确映射，并在网关中完成 QoS 语义的转换与降级处理。