3. DDS标准与规范
DDS（Data Distribution Service，数据分发服务）并不是单一厂商的私有中间件，而是一套由OMG（Object Management Group）维护的开放标准族。理解DDS工程实践，首先要区分三个层次：API与语义层（DDS规范）、互操作协议层（DDSI-RTPS）以及安全与扩展层（DDS Security等插件规范）。只有把这三层关系理清，才能在选型、部署和排障时判断“问题出在接口、协议还是安全策略”。
一、OMG DDS规范体系的三层结构
OMG DDS规范体系可以概括为“一个核心、两条主线、多个扩展”。核心是DDS本身，定义了以主题（Topic）为中心的发布/订阅数据模型、QoS策略、类型系统与监听机制；两条主线分别是面向应用的DDS API规范和面向传输的DDSI-RTPS互操作协议；多个扩展则包括DDS Security、DDS-XTypes、DDS-RPC、DDS-TSN等。
其中，DDS API规范关注“应用如何写代码”，例如DataWriter、DataReader、DomainParticipant等实体；DDSI-RTPS关注“不同厂商实现如何在同一网络上互相发现并交换数据”。二者是“语义”与“线缆”的关系：API保证编程模型一致，DDSI-RTPS保证跨实现互通。
二、DDSI-RTPS：互操作的“线缆协议”
DDSI-RTPS（Real-Time Publish-Subscribe）是DDS实现之间互操作的强制协议。它规定了报文的二进制格式、端点发现流程、可靠性机制与传输绑定。RTPS的核心机制包括：
- SPDP（Simple Participant Discovery Protocol）：参与者通过周期性组播/单播公告自己的存在，包含GUID、域ID、传输地址等。
- SEDP（Simple Endpoint Discovery Protocol）：在参与者之间交换DataWriter/DataReader的端点信息、主题名、类型名与QoS。
- 心跳与确认：通过HEARTBEAT、ACKNACK实现可靠传输，支持Best-Effort与Reliable两种QoS。
- 传输绑定：默认UDP，可扩展TCP、共享内存（SHM）等，适应不同网络环境。
工程中最常见的互操作故障是“同一域内两个厂商的DDS无法发现”。此时应优先检查：域ID是否一致、组播地址是否可达、RTPS端口计算是否冲突、类型名与主题名是否完全匹配。DDSI-RTPS的端口计算公式为：
PB = 7400 + 250 * domainId
DG = PB + 10 // 组播发现端口
PG = PB + 20 // 单播发现端口
D0 = PB + 30 // 用户数据端口起始
D1 = PB + 40
若域ID为0，则发现端口为7410/7420；若域ID为1，则为7660/7670。端口冲突或防火墙拦截是跨主机互操作失败的高频原因。
三、DDS Security：安全插件规范
DDS Security 1.1是OMG在DDS之上定义的安全插件规范，采用“插件化”设计，不改变原有DDS API，而是通过SPI接口注入安全能力。其核心组件包括：
| 插件 | 作用 | 典型配置 |
|---|---|---|
| Authentication | 身份认证与密钥交换 | PKI-DH、预共享密钥 |
| Access Control | 控制谁能发布/订阅哪些主题 | 权限文档（Permissions CA） |
| Cryptographic | 数据加密、签名与完整性 | AES-GCM、HMAC-SHA256 |
| Logging | 安全事件审计 | 本地日志或远程审计 |
| Data Tagging | 为数据打安全标签 | 主题级/实例级标签 |
安全插件通过Governance与Permissions两类XML文档进行策略配置。Governance定义域级安全策略（是否加密、是否认证），Permissions定义具体参与者的主题访问权限。一个典型的权限片段如下：
<permissions>
<grant name="publisher_grant">
<subject_name>CN=Publisher</subject_name>
<allow_rule>
<domains><id>0</id></domains>
<publish><topics><topic>SensorData</topic></topics></publish>
</allow_rule>
</grant>
</permissions>
四、版本演进关系与选型建议
DDS规范自2004年发布1.0以来，经历了多次演进。DDS 1.2/1.4主要完善QoS与类型系统；DDSI-RTPS 2.0引入更高效的发现与传输；DDS Security 1.0/1.1补齐安全能力；DDS-XTypes 1.3支持类型演化与动态类型；DDS-RPC 1.0将DDS扩展为请求/响应模式。各版本之间并非简单替代，而是“核心稳定、扩展叠加”的关系。
五、案例复盘：跨厂商互操作排障
某工业项目使用A厂商DDS发布设备状态，B厂商DDS订阅。现象是同一主机可发现，跨主机无法发现。排查过程如下：
- 确认域ID一致，均为0；
- 检查组播地址239.255.0.1是否被防火墙拦截；
- 发现A厂商默认使用UDP组播，B厂商默认关闭组播仅用单播；
- 在B厂商配置中启用组播发现，并统一SPDP周期为1秒；
- 问题解决，跨主机发现恢复正常。
该案例说明：DDSI-RTPS虽然规定了协议，但厂商在传输绑定、发现周期、组播开关等参数上存在差异。工程中应建立“互操作基线配置”，明确域ID、组播地址、发现周期、传输类型与QoS默认值，才能保证多厂商DDS系统稳定互通。