DDS入门指南：Topic、Domain与Partition详解

版权申诉

161 浏览量更新于2024-07-04 收藏 13.86MB PDF 举报

本篇教程名为"The DDS Tutorial"，由Angelo Corsaro, Ph.D. 编写，专为理解和学习实时系统中的Data Distribution Service (DDS)提供深入指南。教程以英文呈现，旨在作为初学者入门DDS的教材，特别关注了DDS的核心概念和技术细节。章节一至四介绍了DDS的基本概念和OMG（Object Management Group）制定的DDS标准，强调了DDS在物联网(IoT)通信，特别是车联网中的应用。章节五到六概述了全球数据空间(Global Data Space)和DDS如何实现实时数据的读写操作。 "Topics"是教程的重点之一，第六章详细讲解了话题(Topic)的类型、键值(Key)、实例(Instance)和样本(Sample)的概念。第十一章深入剖析了话题、域(Domains)和分区(Partitions)，解释了如何通过机制和技术来控制信息的范围。在数据管理方面，第七章提出了主题域和分区的详细结构，包括内容过滤(Content-Filtered Topics)和查询条件(Query Conditions)。接下来的章节着重于数据的读写过程：写作部分讨论了自动和显式生命周期管理，以及无键(无Key)话题的处理。章节十八和十九探讨了写入数据时的阻塞与非阻塞策略，以及访问数据时的read vs. take选择。读取数据的章节涵盖了如何选择样本、迭代器(Iterators)和容器(Container)的使用，以及read/take操作的阻塞与非阻塞模式。此外，还提到了应用程序与DDS协调的方式，如定期的轮询(polling)，这对于某些实时场景可能是理想选择。本教程提供了详尽的DDS教学，帮助读者理解并掌握这个关键的实时通信协议，适用于物联网和车联网项目的开发人员，特别是那些希望深入理解数据分发服务工作原理的人。

Listing 2 shows the code that creates a content-ﬁltered topic for the

TempSensor topic with the expression above. Notice that the content-ﬁltered

topic is created starting from a regular topic. Furthermore it is worth noticing

that the ﬁlter expression is relying on positional arguments %0, %2, etc., whose

actual values are passed via a vector of strings.

Listing 2. Creating a content-ﬁltered topic.

2.4. Query Conditions

For completeness I should mention that DDS also supports Query

Conditions . The main difference between a Query Condition and a Content-

Filtered Topics is that the former does not ﬁlter incoming data, it simply queries

data received and available on an existing reader cache. As a result the

execution of the Query Condition is completely under the user control and

executed in the context of a read as shown in Listing 3. The syntax supported

by Query Expression is identical to that used to deﬁne ﬁlter expression and

listed in Table 4.

// Create the TempSensor topic

dds::Topic<TempSensorType> tsTopic("TempSensor");

// Define the filter expression

std::string filter_expression =

"(temp NOT BETWEEN (%0 AND %1)) \

OR \

(hum NOT BETWEEN (%2 and %3))";

// Define the filter parameters (taking some C++0x liberty)

std::vector<std::string> params =

{"20.5", "21.5", "30", "50"};

// Create the ContentFilteredTopic

dds::ContentFilteredTopic<TempSensorType>

cfTsTopic("CFTempSensor",

tsTopic,

filter_expression,

params);

// Create the DataReader

dds::DataReader<TempSensorType> dr(cfTsTopic);

dds::SampleInfoSeq info;

TempSensorSeq data;

while (true) {

// The only data received will satisfy the filter

// condition of the ContentFilteredTopic

dr.read(data, info);

for (int i =0; i < data.length(); ++i)

std::cout << data[i] << std::endl;

sleep(1);

}

3. Reading and Writing Data

Last month I covered in great details the deﬁnition and semantics of DDS

topics, topic-instances and samples. I also went through domains and partitions

and the role they play in organizing application data ﬂows. In this installment I’ll

examine the mechanisms provided by DDS for reading and writing data.

3.1. Writing Data

As you’ve seen in the ﬁrst two installment of the series, writing data with DDS

is as simple as calling the write method on the DataWriter. Yet, to make you

into a fully proﬁcient DDS programmer there are a few more things you should

know. Most notably, the relationship between writes and topic-instances life-

cycle.

To explain the difference between topics and topic instances I drew the analogy

between DDS topics/topic-instances and classes/objects in an Object Oriented

Programming language, such as Java or C++. Like objects, topic-instances have

(1) an identity provided by their unique key value, and (2) a life-cycle. The topic-

instance life-cycle can be implicitly managed through the semantics implied by

the DataWriter, or it can be explicitly controlled via the DataWriter API.

The topic-instances life-cycle transition can have implications on local and

remote resource usage, thus it is important that you understand this aspect.

3.1.1. Topic-Instances Life-cycle

Before getting into the details of how the life-cycle is managed, let’s see which

are the possible states. A topic instance is in the ALIVE state if there is at least

one DataWriter writing it. An instance is in the NOT_ALIVE_NO_WRITERS

state when there are no more DataWriters writing it. Finally, the instance is in

the NOT_ALIVE_DISPOSED state if it was disposed either implicitly, due to

some default QoS settings, or explicitly, by means of a speciﬁc DataWriter

API call. The NOT_ALIVE_DISPOSED state indicates that the instance is no

more relevant for the system and that it won’t be written anymore (or any-time

soon) by any writer. As a result the resources allocated throughout the system

for storing the instance can be freed. Another way of thinking about this, is that

an instance deﬁnes a live data element in the DDS global data space as far as

there are writers for it. This data element ceases to be alive when there are no

more writers for it. Finally, once disposed this data entity can be reclaimed from

the DDS global data space, thus freeing resources.

3.1.2. Automatic Life-cycle Management

Let’s try to understand the instances life-cycle management with an example. If

we look at the code in Listing I, and assume this is the only application writing

data, the result of the three write operations is to create three new topic

instances in the system for the key values associated with the id = 1, 2, 3 (we

deﬁned the TempSensorType in the ﬁrst installment as having a single attribute

key named id). These instances will be in the ALIVE state as long as this

application will be running, and will be automatically registered, or we could say

associated, with the writer. The default behavior for DDS is then to dispose the

topic instances once the DataWriter object is destroyed, thus leading the

instances to the NOT_ALIVE_DISPOSED state. The default settings can be

overridden to simply induce instances’ unregistration, causing in this case a

transition from ALIVE to NOT_ALIVE_NO_WRITERS.

Listing I - Automatic management of Instance life-cycle.

3.1.3. Explicit Life-Cycle Management

Topic-instances life-cycle can also be managed explicitly via the API deﬁned on

the DataWriter. In this case the application programmer has the control on

when instances are registered, unregistered and disposed. Topic-instances

registration is a good practice to follow whenever an applications writes an

instance very often and requires the lowest latency write. In essence the act of

explicitly registering an instance allows the middleware to reserve resources as

well as optimize the instance lookup. Topic-instance unregistration provides a

mean for telling DDS that an application is done with writing a speciﬁc topic-

instance, thus all the resources locally associated with is can be safely released.

Finally, disposing topic-instances gives a way of communicating DDS that the

instance is no more relevant for the distributed system, thus whenever possible

resources allocated with the speciﬁc instances should be released both locally

and remotely.

Listing 2 shows and example of how the DataWriter API can be used to

the full life-cycle management I’ve changed the default DataWriter behavior

to avoid that instances are automatically disposed when unregistered. In

addition, to maintain the code compact I take advantage of the new C++0x

auto feature which leaves it to the the compiler to infer the left hand side

types from the right hand side return-type. Listing 2 shows an application that

writes four samples belonging to four different topic-instances, respectively

those with id=0,1,2,3. The instances with id=1,2,3 are explicitly registered by

calling the DataWriter::register_instance method, while the instance

with id=0 is automatically registered as result of the write on the DataWriter.

To show the different possible state transitions, the topic-instance with id=1 is

explicitly unregistered thus causing it to transition to the

NOT_ALIVE_NO_WRITER state; the topic-instance with id=2 is explicitly

disposed thus causing it to transition to the NOT_ALIVE_DISPOSED state.

Finally, the topic-instance with id=0,3 will be automatically unregistered, as a

result of the destruction of the objects dw and dwi3 respectively, thus

transitioning to the state NOT_ALIVE_NO_WRITER. Once again, as mentioned

above, in this example the writer has been conﬁgured to ensure that topic-

instances are not automatically disposed upon unregistration.

3.1.4. Keyless Topics

Most of the discussion above has focused on keyed topics, but what about

keyless topics? As explained in the last installment of the series, keyless topics

are like singletons, in the sense that there is only one instance. As a result for

keyless topics the the state transitions are tied to the lifecycle of the data-writer.

int main(int, char**) {

dds::Topic<TempSensorType> tsTopic(“TempSensorTopic”);

dds::DataWriter<TempSensorType> dw(tsTopic);

TempSensorType ts;

//[NOTE #1]: Instances implicitly registered as part

// of the write.

// {id, temp hum scale};

ts = {1, 25.0F, 65.0F, CELSIUS};

dw.write(ts);

ts = {2, 26.0F, 70.0F, CELSIUS};

dw.write(ts);

ts = {3, 27.0F, 75.0F, CELSIUS};

dw.write(ts);

sleep(10);

//[NOTE #2]: Instances automatically unregistered and

// disposed as result of the destruction of the dw object

return 0;

}

Listing 2 - Explicit management of topic-instances life-cycle

3.1.5. Blocking or Non-Blocking Write?

One question that you might have at this point is wether the write is blocking

or not. The short answer is that the write is non-blocking, however, as we will

see in the next installment there are some cases in which, depending on QoS

settings, that the write might block to avoid data-loss.

3.2. Accessing Data

DDS provides two different mechanisms to access data, each of which allowing

to control what data is accessed and to be informed about data availability. Let’s

see in details what does this boils down to.

3.2.1. Read vs. Take

The DDS provides data access via the DataReader class which exposes two

semantics for data access: read and the take.

The read semantics, implemented by the DataReader::read methods, gives

access the data received by the DataReader without removing it from its local

int main(int, char**) {

dds::Runtime runtime;

dds::Topic<TempSensorType> topic("TempSensorTopic");

//[NOTE #1]: Avoid topic-instance dispose on unregister

dds::DataWriterQos dwqos;

dwqos.set_auto_dispose(false);

//[NOTE #2]: Creating DataWriter with custom QoS.

// QoS will be covered in detail in article #4.

dds::DataWriter<TempSensorType> dw(topic, dwqos);

TempSensorType data = {0, 24.3F, 0.5F, CELSIUS};

dw.write(data);

TempSensorType key;

key.id = 1;

//[NOTE #3]: Using C++0x “auto” to keep code more compact

//[NOTE #4] Registering topic-instance explicitly

auto diw1 = dw.register_instance(key);

key.id = 2;

auto diw2 = dw.register_instance(key);

key.id = 3;

auto diw3 = dw.register_instance(key);

data = {1, 24.3F, 0.5F, CELSIUS};

diw1.write(data);

data = {2, 23.5F, 0.6F, CELSIUS};

diw2.write(data);

data = {3, 21.7F, 0.5F, CELSIUS};

diw3.write(data);

// [NOTE #5]: unregister topic-instance with id=1

diw1.unregister();

// [NOTE #6]: dispose topic-instance with id=2

diw2.dispose();

//[NOTE #7]:topic-instance with id=3 will be unregistered

// as result of the diw3 object destruction

//[NOTE #8]: topic instance with id=0 will be unregistered as

// result of the dw object destruction

return 0;

}

剩余172页未读，继续阅读

车联网安全杂货铺

粉丝: 748
资源: 59

DDS入门指南：Topic、Domain与Partition详解

"DDS DCPS文档版本1.4发布：标准规范与机器可读文件

OpenDDS开发指南：金属材料手册与DDS应用

OpenDDS 3.12实现：OMG DDS与RTPS规范详解

ADI-tutorial-DDS.pdf

用于AD9834波形发生器(DDS)的幅度控制电路

Data Distribution Service Tutorial.pdf

Tutorial07_11_1.rar

A_Technical_Tutorial_on_Digital_Signal_Synthesis.pdf

ebf_ep4ce10_pro_tutorial_code_20210302.rar

DDS技术原理及系统设计时序图解析

最新资源