Professional Documents
Culture Documents
Gerardo Pardo-Castellote
Bert Farabaugh
Rick Warren
Abstract
To address the communication needs of distributed applications, a new specification is available called
Data Distribution Service for Real-Time Systems (DDS). Many different types of distributed applications
can use the DDS infrastructure as the backbone for their data communications.
This paper presents an overview of distributed applications, describes DDS specification and its
components, and discusses how DDS can help developers design distributed applications.
2005 Real-Time Innovations. All Rights Reserved. Last Revision: 12 August 2005
Efficient use of transport bandwidth from the appropriate publishers and presenting
Supports one-to-one, one-to-many, many-to- the data to the interested user application.
one, and many-to-many communications What Does Data-Centric Mean?
Large number of configuration parameters
that give developers complete control of Data-centric communication provides the ability
each message in the system to specify various parameters like the rate of
publication, rate of subscription, how long the
data is valid, and many others. These Quality of
Service (QoS) parameters allow system
designers to construct a distributed application
based on the requirements for, and availability
of, each specific piece of data.
A data-centric environment allows you to have a
communication mechanism that is custom-
tailored to your distributed applications specific
requirements.
Solutions for using a publish-subscribe
communication mechanism have typically been
Figure 2. The DDS Infrastructure accomplished with proprietary solutions. The
Data Distribution Service formalizes the data-
As shown in Figure 2, DDS provides an centric publish-subscribe communication
infrastructure layer that enables many different paradigm by providing a standardized interface.
types of applications to communicate with each
other. In the example shown in Figure 1, DDS would
be a software module on both the embedded SBC
The DDS specification is governed by the Object and the workstation. On the embedded SBC side,
Management Group (OMG), which is the same DDS would enable publishing of the temperature
organization that governs the specifications for sensor data with specified QoS parameters. On
CORBA, UML and many other standards. A the workstation side, DDS would enable a
copy of the DDS specification can be obtained declared subscription to receive the temperature
from the OMG website at www.omg.org. sensor data according to specified QoS
What is Publish-Subscribe? parameters.
Publish-subscribe applications are typically How Does DDS Help Developers?
distributed applications with endpoint nodes that By relying on a specification that governs the
communicate with each other by sending dissemination of data, distributed application
(publishing) data and receiving (subscribing) developers can concentrate on the operation of
data anonymously. Usually the only property a their specific applicationwithout worrying
publisher needs in order to communicate with a about how they are going to communicate with
subscriber is the name and definition of the data. the other applications in the environment.
The publisher does not need any information
about the subscribers, and vice versa. Applications that gather or generate data
(through interfaces with sensors, files, on-board
As long as the interested applications know what data computations, etc.) can use the DDS
data is being communicated, a publish-subscribe framework to send (publish) their data.
infrastructure is capable of delivering that data to
the appropriate nodes without having to set up Similarly, applications that need data from other
individual connections. Publishers are applications in a distributed environment can use
responsible for gathering the appropriate data the DDS framework to receive (subscribe to)
and sending it out to all registered subscribers. specific data items. DDS handles all of the
Subscribers are responsible for receiving data communications between publishers and
subscribers.
2005 Real-Time Innovations. All Rights Reserved. Last Revision: 12 August 2005
By employing a publish-subscribe
methodology for data communications, DDS An Overview of DDS Components
provides abstract communications between data
The specification for DDS is broken up into two
senders and receivers. Publishers of data are not
distinct sections. The first section covers Data-
required to know about each individual receiver,
Centric Publish-Subscribe (DCPS) and the
they only need to know about the specific data
second section covers the Data Local
type that is being communicated. The same is
Reconstruction Layer (DLRL).
true for subscribers. Subscribers do not need to
know where the published data is coming from; DCPS is the lower layer API that an application
they only need to know about the specific data can use to communicate with other DDS-enabled
type they wish to receive. applications. DLRL is the upper layer part of the
specification that outlines how an application can
interface with DCPS data fields through their
own object-oriented programming classes.
DLRL is an optional layer within the DDS
specification.
For the purpose of understanding the basics and
benefits of DDS, this paper will concentrate on
the DCPS portion of the specification. DCPS is
comprised of the following primary entities:
Domain
Domain Participant
Data Writer
Figure 3. Simple Distributed Application w/ DDS Publisher
Data Reader
In Figure 3, the Embedded SBC publishes data
Subscriber
packets with a simple write call using the
current temperature sensor data as a parameter. Topic
On the workstation side, the application may Figure 4 shows how entities in DDS are related.
either wait for data to become available or it can The following sections contain more detailed
set up a callback routine that will receive the data descriptions of the entities used within DDS.
immediately upon arrival. Once data is available,
the workstation application can take the data
from the DDS middleware.
2005 Real-Time Innovations. All Rights Reserved. Last Revision: 12 August 2005
capability without breaking it.
Domains and Domain Participants
The domain is the basic construct used to bind In Figure 6, a new domain is added to the existing
individual applications together for application. The new messages in Domain C will
communication. A distributed application can not affect the existing messages in the old
elect to use a single domain for all its data-centric domains. The new domain provides an isolated
communications. container for testing the new functionality. After
testing is complete, the new applications (App 7
Figure 5 shows an example of a system with six
and App 8) can be added to the original system
applications on five nodes, all communicating in
simply by changing their specified domain.
the same domain.
N3 App 3 N5 App 6
N3 App 3 N5 App 6
Pub/Sub Subscribe
Pub/Sub Subscribe
Figure 5. Single Domain System Domain C
Added Func. N7 App 8
N6 App 7
Pub/Sub Pub/Sub
All Data Writers and Data Readers with like data
types will communicate within this domain. Figure 6. Multiple Domains System
DDS also has the capability to support multiple
domains, thus providing developers a system that An application uses an object called a Domain
can scale with system needs or segregate based Participant to represent its activity within a
on different data types. When a specific data domain. The Domain Participant object enables a
instance is published on one domain, it will not developer to specify default QoS parameters for
be received by subscribers residing on any other all data writers, data readers, publishers and
domains. subscribers in the corresponding domain. Default
listener callback routines can be set up to handle
Multiple domains provide effective data events or error conditions that are reported back
isolation. One use case would be for a system to to the application by the DDS infrastructure. This
be designed whereby all Command/Control makes it easy to specify default behavior that the
related data is exchanged via one domain while application will follow when it receives a
Status information is exchanged within another. subscription for which it hasnt set up specific
In Figure 6, three applications are communicating listener routines for the underlying entities:
Command/Control data in Domain A and three Publisher, Subscriber, Data Writer or Data
other applications are communicating Status data Reader.
in Domain B. For very large systems, developers Data Writers and Publishers
may want to have different domains for each
functional area in their overall system. Data Writers are the primary access point for an
application to publish data into a DDS data
Multiple domains are also a good way to control domain. Once created and configured with the
the introduction of new functionality into an correct QoS settings, an application only needs to
existing system. Suppose you have a distributed perform a simple write call, such as in this C++
application that has been tested and validated as example:
working correctly and then need to add new retcode = writer->write(data, instance_handle);
functionality. You want to minimize the impact The sending application controls the maximum
of the new functionality and preserve the existing rate at which data is published. Subscribers may
2005 Real-Time Innovations. All Rights Reserved. Last Revision: 12 August 2005
have different requirements for how often they The second method is to poll or query the Data
want to receive data. Some subscribers may want Reader to determine if data is available.
every individual sample of data, while others may
The last method is to set up a WaitSet, on
want data at a much slower rate. This can be
which the application waits until a specified
achieved by specifying a different time-based
condition is met and then accesses the data from
filter QoS for each subscriber. If a time-based
the Data Reader.
filter is specified for an associated subscriber,
then the publisher could be implemented to not
send data to that subscriber any faster than is Topic
take()
read()
required. This would therefore reduce overall Domain
Participant S
network bandwidth. When the write is executed,
the DDS software will move the data from its DR Listener,
current container, Data Writer, into a Publisher Polling,
for sending out to the DDS Domain. Figure 7 Subscriber Conditions
shows how the entities (Domain Participant,
Topic, Data Writer, and Publisher) needed to
Domain
publish data are connected.
Fig. 8 Subscription Model
Data
Topic Sample
Domain
Participant S
Having these three methods gives developers
DW
flexibility in accessing data. Accessing data is
facilitated by calling take( ) or read( ) (the take()
Publisher call removes the data from the middleware after
returning it; the read() allows the same data to be
retrieved multiple times). Just as Publishers are
Domain
used to group together Data Writers, Subscribers
Fig. 7 Publication Model are used to group together Data Readers. Again,
this allows you to configure a default set of QoS
The Publisher entity is just a container to group parameters and event handling routines that will
together individual Data Writers. A developer can apply to all the Data Readers in that Subscribers
specify default QoS behavior for a Publisher and group.
have it apply to all the Data Writers in that
Publishers group. Topics
Topics provide the basic connection point
Data Readers and Subscribers
between publishers and subscribers. The Topic of
A Data Reader is the primary access point for an
a given publisher on one node must match the
application to access data that has been received
Topic of an associated subscriber on any other
by a Subscriber. Figure 8 shows the entities
node. If the Topics do not match, communication
associated with subscriptions. Once created and
will not take place.
configured with the correct QoS, an application
can be notified that data is available in one of A Topic is comprised of a Topic Name and a
three ways: Topic Type. The Topic Name is a string that
Listener Callback Routine uniquely identifies the Topic within a domain.
Polling the Data Reader The Topic Type is the definition of the data
Conditions and WaitSets contained within the Topic. Topics must be
uniquely defined within any one particular
The first method for accessing received data is to domain. Two Topics with different Topic Names
set up a listener callback routine that DDS will but the same Topic Type definition would be
run immediately when data is received. You can considered two different Topics within the DDS
execute your own specific software inside that infrastructure.
callback routine to access the data.
2005 Real-Time Innovations. All Rights Reserved. Last Revision: 12 August 2005
The DDS specification suggests that types be Keys, you would need to create individual Topics
defined in Interface Definition Language (IDL) for each of the different SBC/temperature sensor
files. IDL is the OMG standard language for pairs. Topic names for these Topics might be:
defining object/data interfaces. The syntax for
Temperature_Sensor_1
IDL is very similar to C++. The following
primitive data types are supported by IDL: Temperature_Sensor_2
Temperature_Sensor_3
char And so on
octet
Therefore, even though each Topic is comprised
short
of the same data type, there would still be
unsigned short
multiple Topics. If you wanted to add another
long sensor into the environment, you would have to
unsigned long create a new Topic, Temperature_Sensor_N.
long long
unsigned long long But with Keys, you would only need one Topic,
float named temperature, with the following Type
double definition:
long double struct Temperature {
boolean float data;
enum unsigned long sensorId; //key
array and bounded sequence of the above };
types When a Subscriber receives data from all of the
string Publishers of temperature, it will sort the data
For example, here is a definition of a sample type and present it to the application relative to its Key
found in a file named randomNumber.idl: value, which in this case is the sensorId. New
sensors could be added without creating a new
struct RndNum { Topic. The publishing application would just
float data; need to fill in the new sensorId when it was ready
short processed; to publish that data.
unsigned long seqNumber; //key
}; An application can also have a situation where
there are multiple publishers of the same Topic
In this example, the type RndNum is a Topic with the same Key defined. This enables the
Type. The Topic Name may be any string chosen application to provide redundancy on a Topic.
by the application, such as Random Numbers Redundancy is created by setting the QoS
or Radar Samples. parameters Ownership and Ownership Strength.
Topic Keys For a discussion on these QoS parameters, please
refer to Appendix A.
Within the definition of the Topic Type, one or
more data elements can be chosen to be a Key MultiTopics & ContentFilteredTopics
for the type. The DDS middleware will use the In addition to standard Topics, there are also
Key to sort incoming data. By specifying one constructs in place for MultiTopics and
data element to be a Key, an application can then ContentFilteredTopics.
retrieve data from DDS that matches a specific
key, or matches the next Key in a sequence of A MultiTopic is a logical grouping of several
Keys. The container for holding one Keys worth Topics. It allows an application to select fields
of data is defined as an Instance. from multiple types and recombine them into a
new type (something like an SQL SELECT
Keys provide scalability. In the case of the statement). As a large application evolves,
distributed application shown in Figure 2, MultiTopics can be a powerful tool: the data
suppose there were multiple embedded SBCs, types used within a subsystem may change, but
each with their own temperature sensor. Without the contents of those new types can be
2005 Real-Time Innovations. All Rights Reserved. Last Revision: 12 August 2005
recombined to look like the old types, preserving Summary
the interface between subsystems.
The Data Distribution Service is a new OMG
A ContentFilteredTopic allows you to declare a specification that creates a very simple
filter expression by which only individual data architecture for data communication, while
samples of the specified Topic would be received enabling very complex data patterns.
and presented to the application. In our simple
Topics allow endpoint nodes to be abstracted
example, this would allow some subscribers to
from each other, so nodes can enter and leave the
only receive and process data when a temperature
distributed application dynamically. DDS is
exceeded a specific limit.
data-centricall the QoS parameters can be
Quality of Service in DDS changed on a per endpoint basis. This per
endpoint configurability is the key to supporting
The provision of QoS on a per-entity basis is a
complex data communication patterns.
significant capability provided by DDS. Being
able to specify different QoS parameters for each DDS provides an API for sending and receiving
individual Topic, Reader or Writer gives data. It frees developers from having to worry
developers a large palette from which to design about any network programming.
their system. This is the essence of data centricity Simply put, DDS distributes data where you
within DDS. want it, when you want it. The publish-subscribe
The DDS QoS parameters are: model makes it easy to specify the where.
Data-centricity enables the when.
Deadline
Destination Order
Durability For additional information:
Entity Factory
Group Data
Dr. Gerardo Pardo-Castellote is chairman of the
History
OMG Data Distribution Service Finalization Task
Latency Budget Force and CTO of RTI in Santa Clara, CA. He
Lifespan can be reached at gerardo_pardo@omg.org. Bert
Liveliness Farabaugh and Richard Warren are members of
Ownership the engineering staff at RTI. RTI created the first
Ownership Strength commercially available implementation of the
Partition DDS specification with its NDDS product line.
Presentation
Reader Data Lifecycle This paper derives from the OMG specification
Reliability Data Distribution Service for Real-Time Systems
Resource Limits available free of charge from www.omg.org.
Time-Based Filter
Topic Data Please contact us if you have additional questions
Transport Priority or comments regarding this whitepaper:
User Data
Real-Time Innovations
Writer Data Lifecycle
3975 Freedom Circle
Appendix A contains a detailed discussion of Santa Clara, CA 94089
what each QoS parameter is and how it is used to http://www.rti.com
control communication. Through the combination 408.200-4700
of these parameters, a system architect can
construct a distributed application to address an
entire range of requirements, from simple
communication patterns to complex data
interactions.
2005 Real-Time Innovations. All Rights Reserved. Last Revision: 12 August 2005
Appendix A: Quality of Service Parameters Destination Order (T, DR)
This appendix presents detailed information on Destination Order determines how a Subscriber
each of the QoS parameters found in DDS. Each handles a situation in which it receives samples in
section contains: a different order from that in which they were
sent. The application can specify whether the
QoS parameter name
samples should be read in the order in which they
Entities to which the QoS applies
were sent or in the order in which they were
Description
received.
Architectural benefits
If a Data Reader receives multiple samples of the
The entities to which each QoS parameter applies same instance, it needs some criteria for deciding
are noted next to the parameter name, using the how to logically order those sample values. Each
following abbreviations: sample includes two timestamps, a source
DP = Domain Participant timestamp and a destination timestamp. This
DR = Data Reader parameter specifies which timestamp should be
DW = Data Writer used for ordering the samples.
T = Topic There are two possible settings:
Pub = Publisher By Source TimestampSubscribers order the
Sub = Subscriber samples according to the source timestamp,
which is attached to the data at its time and
Deadline (T, DR, DW)
place of origin. This option ensures that all
Deadline indicates the minimum rate at which a the Subscribers end up with the same final
Data Writer will send data. It also indicates how value for the instance. That is, all Subscribers
long a Data Reader is willing to wait for new will process the samples in the same order.
data. By Reception TimestampSubscribers order
This policy is useful for cases where a Topic is the samples according to the destination
expected to have each instance updated timestamp, which is attached to the data
periodically. The default is a value of infinity; when it reaches the Subscriber. Since the
that is, there is no deadline. samples may reach each Subscriber at
different times, the samples may be
For example, suppose an application requires a processed in different orders at each
new Position Command to be received every Subscriber node. Therefore, the various
100 milliseconds. If that deadline passes without subscribers may end up processing the
a new command, the application will be notified samples in different orders and thus end up
and can apply a default safe command until a new with different final values. This is the default
appropriate position command comes in. value.
Architectural Benefits: Architectural Benefits:
Allows each Data Writer to specify how fast Allows an application to specify in what
it is able to publish data. order it wants to receive the data from the
Allows each Data Reader to specify how fast DDS framework
it needs to receive data.
Indicates when a particular data source is not
available, or that something may be wrong
with a particular data source.
Provides a way to set a time period during
which a Data Reader will use the highest
strength data source received when using
multiple Data Writers.
Allows an application to be notified
immediately if a deadline is missed.
2005 Real-Time Innovations. All Rights Reserved. Last Revision: 12 August 2005
of the factory would need to be enabled
Durability (T, DR, DW) separately by the application before use. This
Durability specifies whether DDS will make past parameter should help simplify overall code
samples of data available to newly joining Data development by eliminating the need for specific
Readers in the system. Durability has three enable functions to be called.
possible settings: Architectural Benefits:
Volatilethe system will not keep any past Allows a developer to set a default enable
samples of data. This is the default setting. upon creation of entities created under a
Transientthe system will keep a certain factory.
number of samples (determined by the
Resource Limits and History parameters) in
memory. Group Data (Publisher, Subscriber)
Persistentthe system will keep all past
samples on some type of non-volatile Group Data is extra information that is attached
memory, such as a hard disk. This allows to the topic that may be accessed by the
subscribers to join the system at any time and application when a new entity, Publisher or
be able to receive the past N samples of Subscriber, is discovered in the domain. Group
publication data. Data is very similar to the User Data and Topic
Data QoS parameters, but is intended to be
For example, if you want to save all publications applied on a per Publisher or Subscriber basis.
from a temperature sensor, you could set the Data
Readers Durability to Persistent. Then each This QoS could be used to allow a system
reading of the sensor would be saved off to disk. designer to apply application level policies that
are similar to the capabilities that are provided by
Architectural Benefits: DDS with the Partition QoS parameter. One
Enables new nodes that join an existing example would be that an application could
domain to receive past publication data further impose additional segmentation between
Determines how past data shall be stored: topics by filtering on information contained
o Not at all (volatile) within the Group Data QoS data field. While
o In memory (transient) DDS would perform segmentation based on
o On disk (persistent) matching Partition strings, the application would
Persistent setting allows easy access to past use Group Data in a similar fashion. Just like in
messages for post-mission analysis User Data or Topic Data (see descriptions
below), this QoS parameter could be used for
Entity Factory (DP, Pub, Sub) authentication or identification purposes as well.
As show in figure 9, this publisher could contain
All DDS entities must be enabled before they
an Identifier, Group Name or Signature that could
will become visible on the network and can be
then be accessed by listener routines associated
used for communication. The Entity Factory QoS
with corresponding DataWriter or DataReader
policy is a mechanism whereby a user can
entities.
indicate whether entities should be automatically
enabled upon creation by their factory or whether
Topic
enabling should be deferred to a later time of the Domain
Participant S Group Data:
users own choosing. This parameter, when
TRUE, and applied to a Domain Participant, Identifier
DW
would automatically enable all Publishers, Group Name
Subscribers and Topics created by the Domain Publisher Signature
Participant factory. Also, when TRUE and
applied to Publisher or Subscriber, would
automatically enable Data Writers or Data Domain
2005 Real-Time Innovations. All Rights Reserved. Last Revision: 12 August 2005
N1 App 1 N4 App 4 applications. If the signature located within the
Pub: A Pub: D,E User Data field does not match the approved
Sub:B Sub: A
signature list, then connections with those entities
Domain could be refused.
This QoS could be used in conjunction with these
N3 App 3 N5 App 6 functions to prevent unwanted messages from
Pub: B,C Sub: A,B appearing in the system:
Sub: A,D,E
Figure 10. Topic Data Example
ignore_participant( )
ignore_publication( )
In the example given in Figure 10, if all the ignore_subscription( )
Topics were to include application and node ignore_topic( )
information as part of the Topic Data, then when Architectural Benefits:
N4 joined the domain it would discover that for Provides security or authentication
its subscription to Topic A, there exist these other information on a per Topic basis
following entities associated to Topic A: Associates system-level information with
Publishers: actual message data
o Node 1, Application 1 Implements publication/subscription
Subscribers: permissions
o Node 3, Application 3
o Node 5, Application 6
Architectural Benefits: Writer Data Lifecycle (DW)
Associates system-level or architectural level Writer Data Lifecycle is a parameter that controls
information with the discovery of a new the automatic removal of data from a Data
entity into the domain. Writers queue if it has recently been
unregistered. For example, if there existed an
Enables the use of authentication or signature
application in which a Data Writer was
data to be associated on a per topic basis.
responsible for reporting the location of several
Transport Priority (T, DW) vehicles within a 100 mile radius, that Data
Writer would contain a separate instance for each
Transport Priority is used to specify, to the vehicle. If one of the vehicles were to leave the
underlying DDS infrastructure, how to set the 100 mile radius, then the Data Writer would no
relative priority of a given Topic message. This longer need to publish the location of that
is only applicable for DDS implantations on top vehicle. The parameter for this QoS policy is
of transport mediums that support setting a called autodispose_unregistered_instances. If
priority. this parameter were TRUE, then when the
Architectural Benefits: application unregisters the instance for the
Allows a developer to assign a priority value vehicle in question, then all data samples for the
to individual Topic messages in the domain. instance will be removed from the history queue
of the Data Writer. If the application does not
unregister the vehicle that left the radius or if this
parameter is set to FALSE, then the data
User Data (T, DP, DR, DW)
associated with that vehicle will be held by the
User Data is extra information that is attached to DDS infrastructure until the Lifespan QoS
the entity that instantiates it. User Data is very parameter has expired.
similar to the Topic Data and Group Data QoS
Architectural Benefits:
parameters, but is intended to be applied on a per
Provides the application an auto removal of
Data Writer and Data Reader basis.
data for Topic instances that have recently
This QoS could be used to set up authentication been unregistered.
between Data Readers and Data Writers or
2005 Real-Time Innovations. All Rights Reserved. Last Revision: 12 August 2005
Appendix B: Glossary of terms used in this document
Callback Routine: A Callback routine is application specific software that is executed directly by the
infrastructure instead of the users thread of execution.
Infrastructure: An infrastructure is a base platform interface whereby all applications that are
registered utilize a common set of capabilities.
Nodes: A node is a computer or any electrical system that is equipped with a central
processing unit. Typically, nodes in a distributed application communicate with
each other over a transport such as Ethernet.
Processes: A process is one or several threads of execution running together in the same
address space to perform a certain functionality.
RTOS Real Time Operating System: A real time operating system is an operating system
that gives a developer greater control over the coordination of tasks running in an
application.
Stale Endpoint: A Stale Endpoint is an application or computer that was once active within a
distributed system, but now has been inactive for a specified period of time.
Threads of execution: A thread of execution relates to one task or thread within an application whereby a
set of commands are called in sequence.
Topic: A Topic in DDS is the means by which data suppliers are paired with consumers.
A Topic is comprised of a Topic name and a Topic type. The type is defined by the
actual structure of data that is to be communicated.
2005 Real-Time Innovations. All Rights Reserved. Last Revision: 12 August 2005