3. DDS核心概念

DDS（Data Distribution Service）是面向分布式实时系统的数据中间件标准，其核心思想是“以数据为中心”，通过发布/订阅解耦通信双方。在车载安全通信场景中，理解DDS的域、主题、数据类型、QoS、发现机制与读写流程，是后续做安全加固与访问控制的基础。本节将把这些概念串成一条可落地的工程认知链。

一、发布订阅模型：从“点对点”到“数据总线”

传统Socket通信需要应用自己维护连接、重连、序列化和路由；DDS则把通信抽象为“数据总线”。发布者（Publisher）通过数据写入者（DataWriter）向某个主题写入样本，订阅者（Subscriber）通过数据读取者（DataReader）接收样本。双方不需要知道对方IP和端口，只依赖相同的域、主题和兼容的QoS。

这种模型带来三个工程收益：第一，空间解耦，节点增减不影响其他节点；第二，时间解耦，发布者与订阅者不必同时在线；第三，平台解耦，同一主题可跨进程、跨芯片、跨操作系统传输。在车载SOA架构中，DDS常被用于雷达、摄像头、底盘、座舱之间的实时数据分发。

二、域、主题与数据类型：通信的“坐标系”

域（Domain）是DDS的隔离边界。不同域中的参与者默认不能互相发现和通信，域ID通常用整数表示。车载系统中可按功能划分域，例如动力域、智驾域、座舱域，避免无关流量互相干扰。

主题（Topic）是数据的逻辑名称，如VehicleSpeed、ObstacleList。主题必须绑定唯一的数据类型，发布者和订阅者只有主题名与类型完全一致才能匹配。主题是访问控制的关键对象：安全策略通常按主题授权，而不是按IP授权。

数据类型（Type）由IDL定义，描述样本的字段、类型和嵌套结构。DDS支持结构体、序列、数组、枚举等。类型不匹配是常见故障，例如发布端用float32 speed，订阅端用double speed，即使主题名相同也无法通信。

struct VehicleSpeed {
    long   vehicle_id;
    float  speed_mps;
    float  confidence;
    long   timestamp_ms;
};
// 主题名与类型共同构成匹配键
Topic<VehicleSpeed> topic(participant, "VehicleSpeed");

三、QoS策略：通信行为的“合同”

QoS是DDS区别于普通消息队列的核心。它描述可靠性、持久性、时限、历史深度、所有权等行为。发布端与订阅端QoS必须兼容，否则不会建立通信。下表列出车载安全通信中最常用的QoS策略。

四、发现机制：节点如何“互相看见”

DDS发现分为两个阶段。第一阶段是参与者发现：新加入的DomainParticipant通过SPDP（Simple Participant Discovery Protocol）周期性地在域内宣告自己，通常使用组播或预配置单播列表。第二阶段是端点发现：参与者之间交换DataWriter/DataReader信息、主题、类型和QoS，由SEDP（Simple Endpoint Discovery Protocol）完成。只有端点发现成功后，才会建立实际的数据通道。

在车载网络中，组播可能被交换机或防火墙限制，因此工程上常配置initial_peers单播列表，或使用Discovery Server集中式发现，以减少组播风暴和发现延迟。安全通信中，发现报文也需要认证与加密，否则攻击者可伪造参与者或端点，实施中间人攻击。

五、数据读写流程与工程案例

一个完整的DDS数据读写流程如下：应用创建DomainParticipant加入指定域；注册IDL数据类型；创建Topic并绑定类型；分别创建Publisher/Subscriber并配置QoS；创建DataWriter/DataReader；发现机制完成端点匹配后，发布端调用write()写入样本，订阅端通过监听器或轮询调用take()取走数据。

案例：某车型智驾域需要将障碍物列表从感知节点发送到规控节点。感知端创建ObstacleList主题，QoS设为RELIABLE、KEEP_LAST depth=5、DEADLINE=50ms；规控端使用相同主题与兼容QoS。若规控端晚启动，DURABILITY设为TRANSIENT_LOCAL可收到最近5帧障碍物，避免“冷启动盲区”。若发现规控端收不到数据，排查顺序应为：域ID是否一致、主题名与类型是否一致、QoS是否兼容、发现单播列表是否可达、安全认证是否通过。