openDDS

openDDS 文档

文档

公司名称法律公告

目录

前言 (4)

第一章简介 (5)

第二章入门 (16)

2.1DCPS 的使用 (16)

2.1.1定义数据类型 (16)

2.1.2处理IDL (17)

2.1.3一个简单消息发布者 (19)

2.1.3.1参与者的初始化 (20)

2.1.3.2注册数据类型和创建一个主题 (21)

2.1.3.3创建一个发布方 (21)

2.1.3.4创建数据写入器并等待订阅方 (22)

2.1.3.5样本出版 (23)

2.1.4设置订阅方 (24)

2.1.4.1初始化参与者 (24)

2.1.4.2注册数据类型和创建一个主题 (25)

2.1.4.3 创建订阅方 (25)

2.1.4.4 创建一个数据读取器和一个监听 (26)

2.1.5 数据读取器监听的实现 (27)

2.1.6 OpenDDS客户中的清理 (29)

2.1.7运行示例 (29)

第三章服务质量 (30)

3.2.6持久服务 (41)

3.2.7资源限制 (42)

3.2.8分区 (42)

3.2.9期限 (43)

3.2.10寿命 (44)

3.2.11用户数据 (44)

3.2.12主题数据 (44)

3.2.13数组 (45)

3.2.14传输优先级 (45)

3.2.16实体工厂 (48)

3.2.17呈现策略 (49)

3.2.18目标顺序 (50)

3.2.19读生命周期 (50)

3.2.20写生命周期 (50)

第四章条件与监听 (47)

第五章内容订阅配置 (48)

第六章内建主题 (49)

第七章配置openDDS (50)

7.1配置方法 (50)

7.2 常见的配置选项 (52)

7.3发现配置 (54)

7.3.1域配置 (55)

7.3.2 DCPSInfoRepo配置应用 (58)

7.3.2.1 多DCPSInfoRepo实例的配置 (61)

7.3.3 DDSI-RTPS发现配置 (63)

7.3.4 静态发现配置 (65)

7.4 传输配置 (68)

7.4.1 概述 (69)

7.4.1.1 传输概念 (69)

7.4.1.2 OpenDDS如何选择传输 (69)

7.4.2 配置文件示例 (70)

7.4.2.1 单个传输配置 (70)

7.4.2.3 使用多种配置 (71)

7.4.3 传输注册示例 (72)

7.4.4 传输配置选项 (73)

7.4.5 传输实例选项 (74)

7.4.5.1 其他常见传输选项 (74)

7.4.5.2 TCP/IP传输配置选项 (75)

7.4.5.3 UDP/IP传输配置选项 (76)

7.4.5.4 IP组播传输配置选项 (76)

7.4.5.5 RTPS_UDP传输配置选项 (79)

7.4.5.6 共享内存传输配置选项 (80)

7.5 日志 (80)

7.5.2 传输层日志 (81)

第八章OpenDDS IDL 选项 (82)

8.1 opendds_idl命令行选项 (82)

第九章DCPS信息仓库 (85)

9.1 DCPS信息仓库选项 (85)

9.2仓库集合 (87)

第十章openDDS的java绑定 (88)

第十一章openDDS的建模SDK (89)

第十二章openDDS的录制和重放 (90)

前言

第一章简介

OpenDDS is an open source implementation of the OMG Data Distribution Service (DDS) for Real-Time Systems Specification v1.4 (OMG Document formal/2015-04-10)

and the Realtime Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol

Specification (DDSI-RTPS) v2.2 (OMG Document formal/2014-09-01). OpenDDS is

sponsored by Object Computing, Inc. (OCI) and is available at https://www.wendangku.net/doc/cb9290784.html,/.

This developer’s guide is based on the version 3.7 release of OpenDDS.

OpenDDS是OMG 实时系统数据分发服务(DDS) 规范1.4版(OMG Document formal/2015-04-10) 和实时发布订阅线上协议- DDS 互操作线上协议(DDSI-RTPS)

规范2.2版(OMG Document formal/2014-09-01)的开源实现. OpenDDS 由Object

Computing, Inc. (OCI) 资助开发，且可以从https://www.wendangku.net/doc/cb9290784.html,/获取到. 本开发

人员指南是基于OpenDDS 3.7的。

DDS defines a service for efficiently distributing application data between participants in a distributed application. This service is not specific to CORBA. The

specification provides a Platform Independent Model (PIM) as well as a Platform Specific

Model (PSM) that maps the PIM onto a CORBA IDL implementation.

DDS制定了一个能在分布式应用的多个参与者之间有效分发数据的服务。

此服务不是专用于CORBA的。该规范提供了平台无关模型（PIM）和将PIM映射

到CORBA IDL 实现的特定平台模型（PSM）。

For additional details about DDS, developers should refer to the DDS specification (OMG Document formal/2015-04-10) as it contains in-depth coverage of all the

service’s features.

对于更多的有关DDS的细节问题，开发者应该参考DDS规范（OMG Document

formal/2015-04-10）,因为其中包含了所有服务特征的进一步说明。

OpenDDS is the open-source C++ implementation of OMG’s DDS specification developed and commercially supported by OCI. It is available for download from

https://www.wendangku.net/doc/cb9290784.html,/downloads.html and is compatible with the latest patch

levels of OCI TAO version 1.6a, 2.0a, and 2.2a, and the latest DOC release.

OpenDDS是OMG DDS规范的开源C++实现，该规范是由OCI公司进行商业

支持和开发的。OpenDDS可以通过网址https://www.wendangku.net/doc/cb9290784.html,/downloads.html 进行下载，并且能够与OCI TAO1.6a,2.0a和2.2a版本的最新补丁以及最新发行的DOC版本兼容。

Note OpenDDS currently implements and is mostly compliant with the OMG DDS version 1.4

specification. See the compliance information in or at https://www.wendangku.net/doc/cb9290784.html,/ for more

information.

OpenDDS目前实现并主要适用于OMG DDS1.4版本的说明。想要阅读更多合规性信息，需访问https://www.wendangku.net/doc/cb9290784.html,/。

1.1. DCPS Overview

1.1. 概述

In this section we introduce the main concepts and entities of the DCPS layer and discuss how they interact and work together.

在本节，我们将介绍有关DCPS层的主要概念和实体，并讨论他们之间如何相互作用以及协同工作的。

1.1.1 Basic Concepts

1.1.1基本概念

Figure 1-1 shows an overview of the DDS DCPS layer. The following subsections define the concepts shown in this diagram.

有关DDS DCPS层的概述，如图1-1所示。下文中给出了图中所示各部分的定义：

1.1.1.1 Domain

The domain is the fundamental partitioning unit within DCPS. Each of the other entities belongs to a domain and can only interact with other entities in that same domain. Application code is free to interact with multiple domains but must do so via separate entities that belong to the different domains.

1.1.1.1 域

域是DCPS中的基本分区单元，一个实体对应一个域，且每一个实体只能与同一域的其他实体之间相互作用。应用程序代码能够任意与多个域建立联系，但是必须通过属于不同域的独立个体才能建立。

1.1.1.2 DomainParticipant

A domain participant is the entry-point for an application to interact within a particular domain. The domain participant is a factory for many of the objects involved in writing or reading data.

1.1.1.2 域的参与者

一个域的参与者是应用程序在特定域内交互的切入点，域的参与者是许多对象参与写入或读取数据的工厂。

1.1.1.3 Topic

The topic is the fundamental means of interaction between publishing and subscribing applications. Each topic has a unique name within the domain and a specific data type that it publishes. Each topic data type can specify zero or more fields that make up its key. When publishing data, the publishing process always specifies the topic. Subscribers request data via the topic. In DCPS terminology you publish individual data samples for different instances on a topic. Each instance is associated with a unique value for the key. A publishing process publishes multiple data samples on the same instance by using the same key value for each sample.

1.1.1.3 标题

标题是发行方和订阅方之间应用程序交互的基本方式，每个标题在其域内都有一个独特的名字和一个特定的数据发布类型。每个标题数据类型能够指定零个或多个字段来组成其关键字。当发布数据的时候，发布过程通常详细说明了该标题。订阅方通过标题来访问数据。在发布的DCPS术语中，个人数据在标题中对不同实例进行采样，每个实例均与一个独特键值相联系。在同一实例中，发布过程通过对每个样本采用相同的键值，发布了多个数据样本。

1.1.1.4 DataWriter

The data writer is used by the publishing application code to pass values to the DDS. Each data writer is bound to a particular topic. The application uses the data writer’s typespecific interface to publish samples on that topic. The data writer is responsible for marshaling the data and passing it to the publisher for transmission.

1.1.1.4 数据写入器

发布数据应用代码通过使用数据写入器将数值传送给DDS。每个数据写入器都绑定到一个特定的标题。该应用程序使用数据写入器的型特异性接口将样本数据发布到标题上。数据写入器负责调配数据并将其传送给发行方。

1.1.1.5 Publisher

The publisher is responsible for taking the published data and disseminating it to all relevant subscribers in the domain. The exact mechanism employed is left to the service implementation.

1.1.1.5 发行方

发行方负责发布的数据，并将其传送给域内相应的订阅方。其所采用的确切的途径将由服务实现来决定。

1.1.1.6 Subscriber

The subscriber receives the data from the publisher and passes it to any relevant data readers that are connected to it.

1.1.1.7 DataReader

The data reader takes data from the subscriber, demarshals it into the appropriate type for that topic, and delivers the sample to the application. Each data reader is bound to a particular topic. The application uses the data r eader’s type-specific interfaces to receive

the samples.

1.1.1.6订阅方

订阅方接收来自发行方的数据，并将其传送到任意一个与之相连接的数据读取器。

1.1.1.7数据读取器

数据读取器从订阅方获得数据，形成适当的标题的类型，并将样本传送给应用程序。每个数据读取器均绑定至一个特定的标题。该应用程序使用数据读取器的类特异性接口来接收样本。

1.1.2 Built-In Topics

The DDS specification defines a number of topics that are built-in to the DDS implementation. Subscribing to these built-in topics gives application developers access to the state of the domain being used including which topics are registered, which data readers and data writers are connected and disconnected, and the QoS settings of the various entities. While subscribed, the application receives samples indicating changes in the entities within the domain.

The following table shows the built-in topics defined within the DDS specification：

1.1.2 标题的内置

DDS规范定义了一些内置于DDS实现的标题。订阅这些内置标题能够让应用程序开发人员访问所使用的域的状态，包括：注册了哪些标题，哪些数据读取器与数据写入器相连接，哪些不连接，以及不同实体的服务质量设置。订阅时，应用程序接收样本指示域内实体的变化。

下表中给出了DDS规范中定义的内置标题：

1.1.3 Quality Of Service Policies

The DDS specification defines a number of Quality of Service (QoS) policies that are used by

applications to specify their QoS requirements to the service. Participants specify what behavior they require from the service and the service decides how to achieve these behaviors. These policies can be applied to the various DCPS entities (topic, data writer, data reader, publisher, subscriber, domain participant) although not all policies are valid for

all types of entities.

1.1.3 服务质量政策

DDS规范中定义了一些由应用程序所使用的服务质量政策来指定对于其服务的质量要求。参与者们指定了他们从服务中所需要的行为，而且，这些服务决定了如何实现这些行为。尽管不是所有的政策都适用于所有类型的实体，但是，这些政策能够被应用到不同的DCPS实体中（标题，数据写入器，数据读取器，发行方，

订阅方，域的参与者）。

Subscribers and publishers are matched using a request-versus-offered (RxO) model. Subscribers request a set of policies that are minimally required. Publishers offer a set of

QoS policies to potential subscribers. The DDS implementation then attempts to match the

requested policies with the offered policies; if these policies are compatible then the association is formed.

The QoS policies currently implemented by OpenDDS are discussed in detail in Chapter 3.

订阅方和发行方匹配使用一个请求-提供（RxO）模型。订阅方请求了一套最低限度所需的政策。发行方为潜在的订阅方提供了一套服务质量政策。DDS实现尝试将订阅方所需的政策与发行方提供的政策进行匹配；如果这些政策是兼容的，那么这两者之间就能够建立连接。

目前，由OpenDDS所执行的服务质量政策将在第三章中进行详细讨论。1.1.4 Listeners

The DCPS layer defines a callback interface for each entity that allows an application processes to “listen” for certain state changes or events pertaining to that entity. For example, a Data Reader Listener is notified when there are data values available for reading.

1.1.4收听装置

DCPS层为每个定义了一个回调接口，该接口允许应用程序进程能够“听取”某些状态的改变或者与实体相关的事件。例如，当有数据值可供阅读时，一个数据读取器的收听装置就会收到通知。

1.1.5 Conditions

Conditions and Wait Sets allow an alternative to listeners in detecting events of interest in DDS. The general pattern is

The application creates a specific kind of Condition object, such as a StatusCondition, and attaches it to a WaitSet.

? The application waits on the WaitSet until one or more conditions become true.

? The application calls operations on the corresponding entity objects to extract the necessary information.

? The DataReader interface also has operations that take a ReadCondition argument. ? QueryCondition objects are provided as part of the implementation of the ContentSubscription Profile. The QueryCondition interface extends the ReadCondition interface.

1.1.5 条件

条件等集允许在DDS参与的检测事件中有可供替换的收听装置。

该应用程序创建了某种特定的条件客体，比如说状态条件，并将其附加到等集上。

? 该应用程序在等集上处于等待状态，直到一个或者更多的条件实现。

? 该应用程序通过调用相应的操作实体对象来提取必要的信息。

? 数据读取器接口也有能够获取读取条件参数的操作。

? 查询条件提供了部分订阅内容的概要文件的实现。查询条件接口扩展了读取条件的接口。

1.2 OpenDDS Implementation

1.2 OpenDD实现

1.2.1 Compliance

OpenDDS complies with the OMG DDS and the OMG DDSI-RTPS specifications. Details of

that compliance follows here.

1.2.1合规性

OpenDDS符合OMG DDS以及OMG DDSI-RTPS规范。合规性遵从以下方面。

1.2.1.1 DDS Compliance

Section 2 of the DDS specification defines five compliance points for a DDS implementation:

1) Minimum Profile

2) Content-Subscription Profile

3) Persistence Profile

4) Ownership Profile

5) Object Model Profile

As of version 2.2, OpenDDS complies with the entire DDS specification (including all optional profiles). This includes the implementation of all Quality of Service policies with the following notes:

? RELIABILITY.kind = RELIABLE is supported only if the TCP or IP Multicast transport (configured as reliable) is used or when the RTPS_UDP transport is used.

? TRANSPORT_PRIORITY is not implemented as changeable.

1.2.1.1 DDS合规性

第二节DDS规范定义了一个DDS实现的五个合规点：

1）最低配置文件

2）订阅内容概要

3）持久性配置文件

4）所有权配置文件

5）对象模型

从版本2.2开始，OpenDDS符合整个DDS规范（包括所有可选的配置文件）。这包含了下列注解的所有服务质量政策的实现：

? RELIABILITY.kind = RELIABLE 只有在使用TCP 或IP 多路传送(配置可靠) 或者是当使用RTPS_UDP 传输时才被支持。

? TRANSPORT_PRIORITY 不作为可变的实现。

1.2.1.2 DDSI-RTPS Compliance

The OpenDDS implementation complies with the requirements of the OMG DDSI-RTPS specification. OpenDDS RTPS Implementation Notes

The OMG DDSI-RTPS specification (formal/2014-09-01) supplies statements for implementation, but not required for compliance. The following items should be taken into

consideration when utilizing the OpenDDS RTPS functionality for transport selection and/or

discovery. Section numbers of the DDSI-RTPS specification are supplied with each item for

further reference.

1.2.1.2 DDSI-RTPS 合规性

OpenDDS实现符合OMG DDSI-RTPS规范的要求。OMG DDSI-RTPS规范(formal/2014-09-01)

Items not implemented in OpenDDS:

1) Writer-side content filtering (8.7.3)

OpenDDS may still drop samples that aren't needed (due to content filtering) by any associated readers -- this is done above the transport layer

2) Coherent sets for PRESENTATION QoS (8.7.5)

3) Directed writes (8.7.6)

4) Property lists (8.7.7)

5) Original writer info for DURABLE data (8.7.8) -- this would only be used for transient and

persistent durability, which are not supported by the RTPS specification (8.7.2.2.1)

6) Key Hashes (8.7.9) are not generated, but they are optional

7) nackSuppressionDuration (Table 8.47) and heartbeatSuppressionDuration

(Table 8.62).

NOTE Items 3 and 4 above are described in the DDSI-RTPS specification. However, they do not have a corresponding concept in the DDS specification.

第二章入门

2.1DCPS 的使用

This chapter focuses on an example application using DCPS to distribute data from a single publisher process to a single subscriber process. It is based on a simple messenger application where a single publisher publishes messages and a single subscriber subscribes to them. We use the default QoS properties and the default TCP/IP transport. Full source code for this example may be found under the $DDS_ROOT/DevGuideExamples/DCPS/Messenger/ directory. Additional DDS and DCPS features are discussed in later chapters.

本章主要解释一个实例应用，其利用DCPS从一个单一发布方到一个单一订阅方的数据分配过程，发布方发布消息和订阅方订阅消息都是基于一个简单的通讯系

统，我们使用默认的Qos属性和默认的TCP/IP传输。本次例子的完整源代码应该

在$DDS_ROOT/DevGuideExamples/DCPS/Messenger/ 目录下，额外的DDS和DCPS

特性将在以后的章节讨论。

2.1.1定义数据类型

Each data type used by DDS is defined using IDL. OpenDDS uses #pragma directives to identify the data types that DDS transmits and processes. These data types are processed by the TAO IDL compiler and the OpenDDS IDL compiler to generate the necessary code to transmit data of these types with OpenDDS. Here is the IDL file that defines our Message data type:

DDS使用的数据类型均是通过IDL定义的，OpenDDS使用# pragma指令确定DDS 传输和处理的数据类型。在openDDS中，这些数据类型通过TAO IDL编译器和

OpenDDS IDL编译器生成必要的代码传输这些格式的数据。这是IDL文件,它定义

了我们的信息数据类型:

type name must be used with this pragma. OpenDDS requires the data type to be a structure. The structure may contain scalar types (short, long, float, etc.), enumerations, strings, sequences, arrays, structures, and unions. This example defines the structure Message in the Messenger module for use in this OpenDDS example.

DCPS_DATA_TYPE的编译指令标注OpenDDS使用的数据类型，一个完全作用域的类型名字必须使用编译指令。OpenDDS需要结构化的数据类型。结构可能包含标量类型(长、短、浮点数、等等),枚举字符串,序列、数组、结构和集合。这个例子定义了用于OpenDDS 通讯模块中的结构信息。

The DCPS_DATA_KEY pragma identifies a field of the DCPS data type that is used as the key for this type. A data type may have zero or more keys. These keys are used to identify different instances within a topic. Each key should be a numeric or enumerated type, a string, or a typedef of one of those types.1 The pragma is passed the fully scoped type and the member name that identifies the key for that type. Multiple keys are specified with separate DCPS_DATA_KEY pragmas. In the above example, we identify the subject_id member of Messenger::Message as a key. Each sample published with a unique subject_id value will be defined as belonging to a different instance within the same topic. Since we are using the default QoS policies, subsequent samples with the same subject_id value are treated as replacement values for that instance.

DCPS_DATA_KEY的编译指令标识的DCPS数据类型的部分，这些被标识的数据类型被用为类型的键。数据类型可以有零个或多个键。这些键是用来识别一个主题

下的不同对象的。每个键应该是一个数字或枚举类型,一个字符串,或以上类型之一

的类型定义。编译指令通过完全作用域类型和成员名称标识类型的键。多个键分别

指定不同的DCPS_DATA_KEY编译指令。在上面的例子中,我们确定的subject_id

成员信使:消息作为一个关键。每个样本发布一个独特的subject_id值将被定义为

在相同的主题下不同的实例。因为我们使用的是默认的QoS策略,后续样品被视为

subject_id相同的值视为该实例的替换值。

2.1.2处理IDL

The OpenDDS IDL is first processed by the TAO IDL compiler.

首先利用TAO IDL编译器处理OpenDDS IDL。

In addition, we need to process the IDL file with the OpenDDS IDL compiler to generate the serialization and key support code that OpenDDS requires to marshal and demarshal the Message, as well as the type support code for the data readers and writers. This IDL compiler is located in $DDS_ROOT/bin/ and generates three files for each IDL

file processed. The three files all begin with the original IDL file name and would appear as follows:

此外,我们需要用OpenDDS IDL编译器处理IDL文件，生成序列化和关键支撑的OpenDDS需要去集合和解列的信息代码,以及数据类型支持代码的读者和作者。

这IDL编译器位于$DDS_ROOT/bin/也为每个处理后的IDL文件生成三个文件。这

三个文件名字都是以原来的IDL文件名称开头，显示如下:

For example, running opendds_idl as follows

例如,运行opendds_idl如下

MessengerTypeSupportImpl.cpp. The IDL file contains the MessageTypeSupport, MessageDataWriter, and MessageDataReader interface definitions. These are

type-specific DDS interfaces that we use later to register our data type with the domain, publish samples of that data type, and receive published samples. The implementation files contain implementations for these interfaces. The generated IDL file should itself be compiled with the TAO IDL compiler to generate stubs and skeletons. These and the implementation file should be linked with your OpenDDS applications that use the Message type. The OpenDDS IDL compiler has a number of options that specialize the generated code. These options are described in Chapter 8.

生成MessengerTypeSupport.idl, MessengerTypeSupportImpl.h,和MessengerTypeSupportImpl.cpp。这个IDL文件包含

MessageTypeSupport,MessageDataWriter,MessageDataReader接口定义。这些

都是特定类型DDS接口,我们使用后登记我们与域的数据类型,发布样本发表的

数据类型,和接收样本。这些实现文件包含这些接口的安装启动。这些已经生成

的IDL文件应该由TAO IDL编译器编译生成存根和骨架。这些存根和骨架与实现

文件应该与你OpenDDS使用消息类型的应用程序联系起来。这OpenDDS的IDL

编译器有许多选项,专门用于生成代码。这些选项在第八章中描述。

Typically, you do not directly invoke the TAO or OpenDDS IDL compilers as above, but let your build environment do it for you. The entire process is simplified when using MPC, by inheriting from the dcpsexe_with_tcp project. Here is the MPC file section common to both the publisher and subscriber

通常,不必直接调用上面的TAO或OpenDDS IDL编译器,而让你的构建环境为你做这些。传承dcpsexe_with_tcp的优势，在MPC的使用下可以简化整个过

程,MPC文件分块共同服务于发布方和订阅方。