个人笔记

外观

DCPS（Data-Centric Publish-Subscribe，以数据为中心的发布/订阅）规范是DDS系列规范最初也是最核心的规范，在某些场合DDS规范指的就是DCPS规范。

DCPS的内容分为三大块：

  • 模型描述，介绍模型中涉及的概念；
  • 接口描述，分模块定义类并定义接口形式及接口功能描述；
  • QoS定义，定义22种QoS的功能及其配置方式。

模型描述 ​

实体概念 ​

DCPS实体模型定义了三层实体，如下图所示：

image.png

  • Domain: 代表一个通信平面，由 Domain ID 唯一标识，只有在同一个域内的通信实体才可以通信；如果考虑车内通信，可以只划分 1 个 Domain，也可以按照交互规则或其他规则，定义多个 Domain；
  • Domain Participant: 代表域内通信的应用程序的本地成员身份；可以理解为“某个进程（或应用实例）加入到一个 DDS 通信域（Domain）后的代表对象”，它是 DDS 实体体系的根节点/入口，负责把应用纳入 DDS 的发现与通信机制中。
  • Topic: 是数据的抽象概念，由 TopicName 标识，关联相应数据的数据类型 (DataType)，如果把车内所涉及的所有 Topic 集合在一起，这样就形成一个虚拟的全局数据空间“Global Data Space”，进一步弱化了节点的概念，所以域参与者已经不是节点的概念了；
  • Publisher: 发布者，发布主题数据，至少与 1 个 DataWriter 关联，通过调用 DataWriter 的相关函数将数据发出去；
  • Subscriber: 订阅者，订阅主题数据，至少与 1 个 DataReader 关联。当数据到达时，应用程序可能忙于执行其他操作或应用程序只是等待该消息时，这样就会存在两种情况，同步访问和异步通知。
  • DataWriter: 数据写入者，类似缓存，把需要发布的主题数据从应用层写入到 DataWriter 中；
  • DataReader: 数据读取者，同样可以理解为一种缓存，从订阅者得到主题数据，随之传给应用层；

image.png

数据描述 ​

概念 说明 标识
主题 最大类，域内唯一的主题名称，并关联1个数据类型。 主题名+类型
实例 主题数据中key成员相同的数据的集合，即使用key成员进一步区分主题数据，可以理解成“子主题”。 InstanceHandle_t
样本 每次向DDS发送一次数据产生一个数据样本。 序列号

接口描述 ​

定义类并定义接口形式及接口功能描述，详见协议规范文档。

image.png

QOS 定义 ​

QoS（Quality of Service）即服务质量。在有限的带宽资源下，QoS为各种业务分配带宽，为业务提供端到端的服务质量保证。例如，语音、视频和重要的数据应用在网络设备中可以通过配置QoS优先得到服务。

DDS（Data Distribution Service）规范中定义了 22种标准QoS（Quality of Service，服务质量）策略，用于精细控制数据通信的行为，涵盖可靠性、持久性、资源管理、发现机制、数据呈现等多个维度。这些策略可应用于不同的DDS实体（如DomainParticipant、Publisher/Subscriber、DataWriter/DataReader、Topic等），并支持匹配协商机制以确保通信双方兼容。

1、与数据传输行为相关的策略 ​

  1. Reliability（可靠性）
    • 控制是否保证数据送达：BEST_EFFORT（尽力而为）或 RELIABLE（可靠传输）。
  2. Durability（持久性）
    • 控制历史数据对晚加入订阅者的可用性：VOLATILE、TRANSIENT_LOCAL、TRANSIENT、PERSISTENT。
  3. History（历史记录）
    • 定义每个实例保留多少样本：KEEP_LAST（保留最近N个）或 KEEP_ALL（保留全部）。
  4. Deadline（截止时间）
    • 要求数据必须在指定周期内更新，否则触发事件。
  5. LatencyBudget（延迟预算）
    • 允许应用指定可接受的最大端到端传输延迟。
  6. Ownership（所有权）
    • 支持独占或共享数据写入权，避免多个发布者冲突。
  7. OwnershipStrength（所有权强度）
    • 配合Ownership使用，数值高的DataWriter获得写入优先权。
  8. Liveliness（活跃性）
    • 检测DataWriter是否“存活”：AUTOMATIC、MANUAL_BY_PARTICIPANT、MANUAL_BY_TOPIC。
  9. TimeBasedFilter（基于时间的过滤）
    • 限制DataReader接收数据的最大频率（如每100ms最多一次）。
设置为 BEST-EFFORT 就一定不可靠吗？ ​

不一定。因为 DDS 里定义的可靠性 QoS 指的是“是否需要 DDS 做额外的可靠保证。”，比如传输层使用的是 TCP 传输或者其他 RTPS 底层的协议已经保证了可靠的传输，这时候配置 DDS 为 BEST-EFFORT 同样可以实现可靠的传输。

设置为 RELIABLE 就一定可靠吗？ ​

答案同样是不一定。可靠的实现方式是确认重传，简单来说就是在接收到告知发送端数据已经收到之前，数据是需要缓存在队列中以备可能需要的重传，既然有队列，就会有长度限制（无论是存储在内存还是文件中，受限于存储空间的大小），当队列到达上限并需要发送新的样本数据时，会有如下的几个处理方式：

  • 替换老的样本数据，这种处理模式下，当被替换的数据丢包需要重传时，无法重传，从而造成“丢包”，就是无法实现可靠；
  • 阻塞等待队列有额外的空间，这种处理模式下可以实现“觉得”的可靠；

2、与资源管理与限制相关的策略 ​

  1. ResourceLimits（资源限制）
    • 限制缓存中最大样本数、实例数、每个实例的样本数等。
  2. Presentation（表示）
    • 控制同一Publisher/Subscriber下多个DataWriter/DataReader的数据呈现顺序和范围（如INSTANCE、TOPIC、GROUP级别）。
  3. Partition（分区）
    • 在Domain内创建逻辑子通道，只有相同Partition的发布/订阅才能通信。
  4. DestinationOrder（目标排序）
    • 控制DataReader接收样本的顺序：按源时间戳（BY_SOURCE_TIMESTAMP）或接收顺序（BY_RECEPTION_TIMESTAMP）。

3、与元数据与用户自定义信息相关的策略 ​

  1. UserData（用户数据）
    • 允许在DomainParticipant、Publisher等实体上附加任意二进制元数据。
  2. TopicData（主题数据）
    • 附加到Topic的元数据，传播给所有基于该Topic的读写器。
  3. GroupData（组数据）
    • 附加到Publisher/Subscriber的元数据，传播给其下属所有DataWriter/DataReader。

4、与生命周期与发现机制相关的策略 ​

  1. EntityFactory（实体工厂）
    • 控制父实体删除时是否自动销毁其创建的子实体（如DataReader是否随Subscriber自动删除）。
  2. WriterDataLifecycle / ReaderDataLifecycle（读写器数据生命周期）
    • 控制DataWriter是否在删除时自动注销其实例；DataReader是否自动清除未更新的实例。
  3. DurabilityService（持久化服务）
    • 配置当Durability为TRANSIENT或PERSISTENT时，外部持久化服务的行为（如清理延迟、历史深度等）。

5、与安全与扩展相关的策略（部分来自DDS Security或XTypes） ​

注：严格来说，以下策略可能属于扩展规范，但在完整DDS实现（如OpenDDS、Fast DDS）中常被计入22种之内。

  1. TransportPriority（传输优先级）
    • 为数据流设置网络传输优先级（依赖底层传输支持）。
  2. Lifespan（生命周期）
    • 指定数据样本的有效生存时间，超时后自动丢弃。
  3. IgnoreLocal（忽略本地）
    • 控制是否忽略来自同一DomainParticipant的本地发布（用于避免自收）。

基于 VitePress 构建

Copyright © 2026 ww1820