DDS (Data Distribution Service) 数据分发服务-规范中文翻译_003

关注

翻译最新推荐文章于 2026-05-22 09:58:19 发布 4.3k 阅读 AI 写同款· GEO 优化 ›

OMG Data Distribution Service(DDS)规范解读-Part1 DDS规范的目的可以概括为“在正确的时间将正确信息有效且稳健地传递到正确的位置。DCPS模型（Data-Centric Publish-Subscribe）被广泛应用到实时性的系统中Publisher–希望向此数据空间提供信息的应用程序声明其意图Subscriber–想要访问此数据空间部分的应用程序声明他们的意图数据模型被定义成数据结构体，每一个结构体都有 topic、typetopic：提供了唯一标识全局数据空间中的某些数据项的标识符。阅读详情

DDS (Data Distribution Service) 数据分发服务-规范中文翻译_003

2.以数据为中心的订阅发布（DCPS）

2.2 平台无关模型（Platform Independent Model ，PIM）

2.2.1概述和设计原理

2.2.1.2 概念大纲

2.2.1.2.1 概述

图 2 1 概述

信息流借助以下实体：发送方的发布者（Publisher） 和 数据写入者（DataWriter）；接收方的订阅者（Subscriber）和数据读取者（DataReader）。

发布者是负责数据分发的对象。它可以发布不同数据类型的数据。数据写入者充当发布者的类型访问者。数据写入者是应用程序用来向发布者传递给定类型的数据对象的存在和数值的必需对象。当数据对象值通过适当的数据写者传递给发布者时，发布者有责任执行分发（发布者将根据自己的QoS或相应数据写入者的QoS执行此操作）。一次发布是通过数据写入者与发布者的关联定义的。此关联表明应用程序有发布数据的意图，该数据由发布者提供的上下文中的数据写入者进行描述。
订阅者是负责接收已发布的数据并使其（根据订阅者的QoS）可用于接收应用程序的对象。它可以接收和分发不同特定类型的数据。应用程序必须使用附加到订阅者的某一类型的数据读取者访问接收的数据。因此，一次订阅是通过数据读取者与订阅者的关联定义的。该关联表明应用程序有订阅数据的意图，该数据由订阅者提供的上下文中的数据读取者进行描述。
**主题（Topic）**对象在概念上适合发布和订阅。订阅必须明确地引用发布，发布必须以这样的方式为订阅所知。主题旨在实现该目的：它关联名称（数据域中唯一），数据类型和与数据本身相关的QoS。除了主题QoS之外，与该主题相关联的数据写入者（DataWriter）的QoS和与数据写入者关联的发布者的QoS控制发布者这一方的行为，与此对应的主题，数据读取者（DataReader）和订阅者QoS控制订阅者这一方的行为。

当应用程序希望发布给定类型的数据时，它必须创建一个发布者（或使用已经创建的一个发布者）和一个具有所需发布的所有特征的数据写入者。类似地，当应用程序希望接收数据时，它必须创建订阅者（或重用已经创建的订阅者）和数据读取者来定义订阅。

2.2.1.2.2 整体概念模型

整体概念模型如图2.2所示。请注意，所有主要通信对象（实体的专业化）都遵循以下统一模式：

支持QoS（由一些QoS策略组成）；QoS为应用程序提供了一种通用机制，用于控制服务的行为并根据需要定制服务。每个实体都支持其自己的专用QoS策略。完整的QoS策略列表及其含义在2.2.3小节中有详细描述。
接受监听器（Listener）; 监听器为中间件提供通用机制，以通知应用程序相关的异步事件，例如订阅的数据到达，违反QoS设置等事件。每个DCPS实体支持其自己的专用类型监听器。监听器与状态条件的变化有关。完整的状态条件在2.2.4小节，Listeners，Conditions和Wait-sets中有描述。
接受状态条件（StatusCondition）（以及数据读取者的一组读取条件对象）; 条件（与WaitSet对象一起）为中间件和应用程序之间的备用通信方式提供支持（即，基于等待而不是基于通知）。完整的状态条件集在2.2.4小节，监听器，条件和等待集中描述。

所有这些DCPS实体都附属于域参与者（DomainParticipant）。域参与者表示域中应用程序的本地成员身份。数据域是一个分布式的概念，它链接所有的应用程序，使得这些应用程序能够相互通信。它代表一个通信平面：只有附属于同一数据域的发布者和订阅者才可以相互通信。

数据域实体（DomainEntity）是一个中间对象，其唯一目的是声明域参与者不能包含其他域参与成员。

图 2 2 DCPS概念模型

在DCPS这一级，数据类型意味着信息将会以原子形式发送出去。

默认情况下，每一次数据更改都是单独且独立地传播，与其他更改不相关。但是，应用程序可能会要求发送方将多次修改当做一次完整的数据发送出去，并在接收方进行对应的解析。此功能将以发布者/订阅者（Publisher/Subscriber）为基础而实现。也就是说，这些关系只能在隶属于同一发布者（Publisher）的数据写入者（DataWriter）对象中指定，并在隶属于同一订阅者（Subscriber）的数据读取者（DataReader）对象中接收恢复。

根据定义，主题对应单个数据类型。但是，多个主题可能指的是相同的数据类型。因此，主题标识单个类型的数据，范围从单个实例到该给定类型的整个实例集合。通过假设的数据类型“Foo”进行展示，如图2.3所示。

图 2 3主题可以标识数据对象实例的集合
如果在同一主题下收集了一组实例，则必须区分不同的实例。通过指定某些数据字段为该数据集的关键字 来实现这种区分。必须向中间件告知关键字的描述（即，组成关键字的数据字段列表）。规则很简单：具有相同键值的不同数值表示同一数据实例的连续值，而具有不同键值的不同数值表示不同的数据实例。如果未提供关键字，则与主题相关的数据集仅存在一个数据实例。
中间件需要知道主题并且该主题可能会进行数据传输。主题对象是通过域参与者提供的创建方法创建的。

发布者方面的交互方式很简单：当应用程序决定要使数据可供发布时，它会调用关联的数据写入者的相应操作（这将触发其所属的发布者）。然而，在订阅者方面，还有更多选择：当应用程序忙于执行其他操作或应用程序只是等待该信息时，相关信息可能会到达。因此，根据应用程序的设计方式，异步通知或同步访问可能更合适。中间件允许两种交互模式，监听器（Listener）用于为同步数据访问提供回调，与一个或多个Condition对象关联的WaitSet提供异步数据访问。

相同的同步和异步交互模式也可用于访问某些改变，这些改变会影响中间件通信状态。例如，当中间件异步检测到不一致时，可能通过这两种方式进行通知。此外，使用内置主题这种方式，应用程序可以作为普通应用数据，通过内置的数据读取者提供可能与应用程序相关的其他中间件信息（例如现有主题的列表）。