3. DDS标准与规范
学习DDS，不能只停留在“发布者发、订阅者收”的直觉层面。真正决定一个DDS中间件能否跨厂商互通、能否安全运行、能否被工具正确解析的，是它背后的一整套OMG规范体系。本节把DDS标准拆成四条主线：DDS规范体系定义API与行为语义，DDSI-RTPS定义线上互操作协议，DDS Security定义安全插件模型，IDL类型系统定义数据在异构系统间的表达方式。理解这四者的分工，才能看懂“为什么同一份IDL在不同厂商实现间能互通，而配置不当却会互不发现”。
一、OMG DDS规范体系：分层看标准
OMG对DDS的标准化并非单一文档，而是一个相互引用的规范族。最上层是DDS v1.4，它规定了DCPS（Data-Centric Publish-Subscribe）的实体模型、QoS策略、监听器与状态机；其下是DDSI-RTPS v2.5，规定发现、匹配、可靠传输与心跳/确认机制；再往下是DDS Security v1.1，以插件方式定义认证、访问控制、加密与日志；此外还有DDS-XTypes用于可扩展类型与类型演化，IDL v4.2作为接口定义语言承载数据类型。它们的关系可以用下面的结构图直观表示。
二、DDSI-RTPS：互操作的真正战场
DDSI-RTPS是DDS实现之间“说同一种语言”的关键。它把DDS的抽象实体映射为RTPS的Participant、Writer、Reader，并规定两类发现：SPDP（Simple Participant Discovery Protocol）通过周期性组播/单播公告参与者，SEDP（Simple Endpoint Discovery Protocol）交换端点与QoS信息，完成匹配。匹配成功后，数据以DATA子消息传输，可靠性由HEARTBEAT与ACKNACK保证，历史数据缺口用GAP声明。
一个常见误区是：认为“Topic名字相同就能通信”。实际上，DDSI-RTPS匹配还要求类型名一致、QoS兼容（如Reliability、Durability、Partition）。若一方为RELIABLE、另一方为BEST_EFFORT，通常仍可匹配但行为降级；若Durability为TRANSIENT_LOCAL而对方为VOLATILE，则历史数据不会补发。排障时应优先检查SPDP是否收到、SEDP是否匹配、QoS是否兼容。
# 典型RTPS发现日志片段（示意）
SPDP: received participant announcement from 192.168.1.22:7410
SEDP: matched writer "TempSensor" -> reader "TempMonitor"
QoS check: Reliability=RELIABLE, Durability=VOLATILE [OK]
DATA: seq=1024, payload=128 bytes
HEARTBEAT: lastSeq=1024, firstSeq=1
ACKNACK: requested 1025.. (none)三、DDS Security：插件式安全模型
DDS Security并不改变DDS API，而是通过插件在发现与数据路径上插入安全能力。核心插件包括：Authentication（基于证书的身份认证，常用PKI-DH）、AccessControl（基于权限文档控制哪些Topic可读写）、Cryptographic（对子消息加密与签名）、Logging（安全事件审计）。启用后，参与者必须先通过认证才能加入域，未授权端点无法匹配。
四、IDL类型系统：数据契约的根基
IDL是DDS的数据契约。它定义struct、enum、union、sequence等类型，并通过注解控制行为：@key标识实例键，@optional允许字段缺失，@mutable支持字段级演化。DDS-XTypes进一步引入TypeObject与TypeIdentifier，使类型信息可在运行时传播，从而支持动态类型发现与跨版本兼容。
| 规范 | 核心职责 | 关键对象/机制 | 典型问题 |
|---|---|---|---|
| DDS v1.4 | API与行为语义 | Entity、QoS、Listener | QoS不兼容导致匹配失败 |
| DDSI-RTPS v2.5 | 互操作线协议 | SPDP、SEDP、HEARTBEAT | 组播被禁、端口冲突 |
| DDS Security v1.1 | 安全插件 | Auth、Access、Crypto | 证书/权限配置错误 |
| DDS-XTypes v1.3 | 类型演化 | TypeObject、@mutable | 类型不匹配、字段丢失 |
| IDL v4.2 | 数据定义 | struct、@key、sequence | 键定义不一致导致实例错乱 |
五、案例与复盘：一次跨厂商互通故障
某项目使用A厂商发布、B厂商订阅，现象是“双方都能看到参与者，但订阅端无数据”。按规范逐层排查：SPDP正常，说明发现层通；SEDP显示端点未匹配，进一步检查发现A端Topic类型名为SensorData，B端为sensor_data，大小写不一致导致类型不匹配。修正IDL并统一类型名后，SEDP匹配成功，数据恢复。复盘结论：DDSI-RTPS的匹配是“类型名+QoS”双重校验，任何一处不一致都会静默失败，必须借助发现日志定位。
综上，DDS标准体系是一条从“数据定义（IDL/XTypes）”到“线上互通（DDSI-RTPS）”再到“安全加固（Security）”的完整链路，而DDS API是这条链路对应用开发者的统一门面。掌握四者的边界与交互，才能在跨厂商、跨网络、跨安全域的工程中稳定交付。