DDS标准详解：实时分布式数据交互核心技术

需积分: 14 70 浏览量更新于2024-07-19 1 收藏 1.7MB PDF 举报

"DDS(Data Distribution Service)是一种标准的实时分布式数据交互协议，广泛应用于大型实时系统的数据通信和仿真。DDS由Object Management Group (OMG)制定，并在2015年4月发布了版本1.4。该规范的主要目标是提供高效、可靠的数据分发服务，以满足高性能和低延迟的需求。其规范文档可以在http://www.omg.org/spec/DDS/1.4找到，包括normative（规范性）和informative（信息性）两个部分，分别提供了idl文件和uml_objecteering.ofp文件供机器处理和参考。DDS的版权由参与制定的公司如Objective Interface Systems, Real-Time Innovations, THALES等共同持有，OMG拥有复制和分发的权利，但不承诺任何公司必须实现此规范。" DDS是Data Distribution Service的缩写，它是面向服务的中间件，专为实时系统设计，特别适合需要高速、高可靠性和低延迟数据交换的环境。DDS的核心概念是“数据就绪发布”(Data-on-Readiness)模型，它通过一个基于主题（Topic）的发布/订阅（Publish/Subscribe）模式来传输数据。在这个模型中，发布者（Publisher）将数据发布到特定的主题，而订阅者（Subscriber）则根据自己的兴趣订阅这些主题，从而实现了数据的解耦通信。 DDS包含几个关键组件和机制： 1. **主题（Topic）**：是数据的逻辑单元，定义了数据的结构和类型。 2. **发布者（Publisher）**：负责生产数据并发布到指定主题。 3. **订阅者（Subscriber）**：负责接收和处理来自主题的数据。 4. **数据读取器（DataReader）**：订阅者的组件，用于接收和处理数据。 5. **数据写入器（DataWriter）**：发布者的组件，用于发布数据。 6. **领域参与者（DomainParticipant）**：每个DDS应用的入口点，代表应用程序在DDS域中的存在。 7. **QoS策略（Quality of Service）**：一组可配置的参数，用于控制数据的传输行为，如可靠性、时延、带宽等。 DDS还提供了强大的数据生命周期管理，包括数据的持久化存储和历史数据访问。此外，DDS支持多种传输层协议，如TCP/IP和UDP，以及跨网络的互操作性，允许不同供应商的DDS实现之间进行无缝通信。 DDS在航空航天、军事、工业自动化、医疗设备、智能交通等领域有广泛应用。例如，在自动驾驶汽车中，DDS可以用来实现实时的传感器数据交换和决策制定；在航空航天领域，它可以用于飞行控制和模拟训练等。 DDS作为一个强大的实时数据交互标准，为复杂分布式系统的通信提供了高效、灵活的解决方案。其规范的不断更新和完善，确保了它能适应各种苛刻的实时通信需求。

4 Data Distribution Service, v1.4

The operation <parameter> can contain the modifier “in,” “out,” or “inout” ahead of the parameter name. If this modifier is

omitted, it is implied that the parameter is an “in” parameter.

In some cases the operation parameters or return value(s) are a collection with elements of a given <type>. This is indicated

with the notation “<type> [ ].” This notation does not imply that it will be implemented as an array. The actual implementation

is defined by the PSM: it may end up being mapped to a sequence, a list, or other kind of collection.

For example, the class named ‘MyClass’ below has a single attribute, named ‘my_attribute’ of type ‘long’ and a single

operation ‘my_operation’ that returns a long. The operation takes four parameters. The first, ‘param1,’ is an output parameter

of type long; the second, ‘param2,’ an input-output parameter of type long; the third, ‘param3,’ is an input parameter (the “in”

modifier is implied by omission) of type long; and the fourth, ‘param4,’ is also an input parameter of type collection of longs.

At the PIM level we have modeled errors as operation return codes typed ReturnCode_t. Each PSM may map these to either

return codes or exceptions. The complete list of return codes is indicated below.

attributes

... ...

operations

... ...

Myclass

attributes

my_attribute long

operations

my_operation long

out: param1 long

inout: param2 long

param3 long

in: param4 long

2. That is, a collection where the type of each element is ‘long’.

Data Distribution Service, v1.4 5

Any operation with return type ReturnCode_t may return OK, ERROR, or ILLEGAL_OPERATION. Any operation that

takes an input parameter may additionally return BAD_PARAMETER. Any operation on an object created from any of the

factories may additionally return ALREADY_DELETED. Any operation that is stated as optional may additionally return

UNSUPPORTED. The return codes OK, ERROR, ILLEGAL_OPERATION, ALREADY_DELETED, UNSUPPORTED, and

BAD_PARAMETER are the standard return codes and the specification won’t mention them explicitly for each operation.

Operations that may return any of the additional (non-standard) error codes above will state so explicitly.

It is an error for an application to use an Entity that has already been deleted by means of the corresponding delete operation on

the factory. If an application does this, the result is unspecified and will depend on the implementation and the PSM. In the

cases where the implementation can detect the use of a deleted entity, the operation should fail and return

ALREADY_DELETED.

2.2.1.2 Conceptual Outline

2.2.1.2.1 Overview

Return codes

OK Successful return.

ERROR Generic, unspecified error.

BAD_PARAMETER Illegal parameter value.

UNSUPPORTED Unsupported operation. Can only be returned by operations

that are optional.

ALREADY_DELETED The object target of this operation has already been

deleted.

OUT_OF_RESOURCES Service ran out of the resources needed to complete the

operation.

NOT_ENABLED Operation invoked on an Entity that is not yet enabled.

IMMUTABLE_POLICY Application attempted to modify an immutable QosPolicy.

INCONSISTENT_POLICY Application specified a set of policies that are not

consistent with each other.

PRECONDITION_NOT_MET A pre-condition for the operation was not met.

TIMEOUT The operation timed out.

ILLEGAL_OPERATION An operation was invoked on an inappropriate object or at

an inappropriate time (as determined by policies set by the

specification or the Service implementation). There is no

precondition that could be changed to make the operation

succeed.

NO_DATA Indicates a transient situation where the operation did not

return any data but there is no inherent error.

6 Data Distribution Service, v1.4

Figure 2.1 - Overview

Information flows with the aid of the following constructs

: Publisher and DataWriter on the sending side; Subscriber and

DataReader on the receiving side.

• A Publisher is an object responsible for data distribution. It may publish data of different data types. A DataWriter acts

as a typed

accessor to a publisher. The DataWriter is the object the application must use to communicate to a publisher

the existence and value of data-objects of a given type. When data-object values have been communicated to the

publisher through the appropriate data-writer, it is the publisher’s responsibility to perform the distribution (the

publisher will do this according to its own QoS, or the QoS attached to the corresponding data-writer). A publication is

defined by the association of a data-writer to a publisher. This association expresses the intent of the application to

publish the data described by the data-writer in the context provided by the publisher.

• A Subscriber is an object responsible for receiving published data and making it available (according to the

Subscriber’s QoS) to the receiving application. It may receive and dispatch data of different specified types. To access

the received data, the application must use a typed DataReader attached to the subscriber. Thus, a subscription is

defined by the association of a data-reader with a subscriber. This association expresses the intent of the application to

subscribe to the data described by the data-reader in the context provided by the subscriber.

Top ic objects conceptually fit between publications and subscriptions. Publications must be known in such a way that

subscriptions can refer to them unambiguously. A Topic is meant to fulfill that purpose: it associates a name (unique in the

domain

), a data-type, and QoS related to the data itself. In addition to the topic QoS, the QoS of the DataWriter associated

3. All those constructs are local to the application part. Actually they play the role of proxies to the service.

4. 'typed' means that each DataWriter object is dedicated to one application data-type.

5. Broadly speaking, a domain represents the set of applications that are communicating with each other. This concept is defined

more precisely in 2.2.1.2.2, Overall Conceptual Model and 2.2.2.2.1, DomainParticipant Class.

Data Distribution Service, v1.4 7

with that Topic and the QoS of the Publisher associated to the DataWriter control the behavior on the publisher’s side, while

the corresponding Topic, DataReader, and Subscriber QoS control the behavior on the subscriber’s side.

When an application wishes to publish data of a given type, it must create a Publisher (or reuse an already created one) and a

DataWriter with all the characteristics of the desired publication. Similarly, when an application wishes to receive data, it must

create a Subscriber (or reuse an already created one) and a DataReader to define the subscription.

2.2.1.2.2 Overall Conceptual Model

The overall conceptual model is shown in Figure 2.2. Notice that all the main communication objects (the specializations of

Entity) follow unified patterns of:

• Supporting QoS (made up of several QosPolicy); QoS provides a generic mechanism for the application to control the

behavior of the Service and tailor it to its needs. Each Entity supports its own specialized kind of QoS policies. The

complete list of QoS policies and their meaning is described in 2.2.3, Supported QoS.

• Accepting a Listener

; listeners provide a generic mechanism for the middleware to notify the application of relevant

asynchronous events, such as arrival of data corresponding to a subscription, violation of a QoS setting, etc. Each

DCPS entity supports its own specialized kind of listener. Listeners are related to changes in status conditions. This

relationship is described in 2.2.4, Listeners, Conditions, and Wait-sets.

• Accepting a StatusCondition (and a set of ReadCondition objects for the DataReader); conditions (in conjunction with

WaitSet objects) provide support for an alternate communication style between the middleware and the application (i.e.,

wait-based rather than notification-based). The complete set of status conditions is described in 2.2.4, Listeners,

Conditions, and Wait-sets.

All these DCPS entities are attached to a DomainParticipant. A domain participant represents the local membership of the

application in a domain. A domain is a distributed concept that links all the applications able to communicate with each other.

It represents a communication plane: only the publishers and the subscribers attached to the same domain may interact.

DomainEntity is an intermediate object whose only purpose is to state that a DomainParticipant cannot contain other domain

participants.

6. This specification made the choice of allowing the attachment of only one Listener per entity (instead of a list of them). The

reason for that choice is that this allows a much simpler (and, thus, more efficient) implementation as far as the middleware is

concerned. Moreover, if it were required, implementing a listener that, when triggered, triggers in return attached 'sub-listeners,'

can be easily done by the application.

剩余179页未读，继续阅读

benojack

粉丝: 5
资源: 5

DDS标准详解：实时分布式数据交互核心技术

Data Distribution Service for Real-time Systems

DDS（datadistributionservice，数据分发服务）简介

DDS规范V1.4版本

使用OpenDDS::DCPS::TransportImpl_rch需要包含什么头文件？

opendds 开源项目

OpenDDS学习笔记

nsert into table sas_data.dds_acct_acct values('45698746456','351654156','0010',...),('45698746369','351657894','0005',...); insert overwrite table sas_data.dds_acct_acct_tmp1 select account_id, business_id,category from sas_data.dds_acct_acct ;

DDS兼容AUTOSAR吗

cyclone DDS

dds和some/ip

最新资源