RTI Connext Micro
Version 2.4.1.0
|
RTI Connext Micro modules following the DDS module definitions. More...
Modules | |
Domain Module | |
Contains the DDS_DomainParticipant class that acts as an entrypoint of RTI Connext Micro and acts as a factory for many of the classes. The DDS_DomainParticipant also acts as a container for the other objects that make up RTI Connext Micro.This image describes the DDS Domain Package, as described by the DDS standard. Note that not all functions and objects shown in this diagram are supported by RTI Connext Micro. Please read the information on the individual types to determine whether a function is supported. | |
Topic Module | |
Contains the DDS_Topic, the DDS_TopicListener interface, and more generally, all that is needed by an application to define DDS_Topic objects and the data types that are associated with DDS_Topic objects. | |
Publication Module | |
Contains the DDS_Publisher, and DDS_DataWriter classes, and more generally, all that is needed on the publication side.This diagram defines the elements that are defined in the DDS specification, and their relationships to each other. Not all entities and functions shown in the diagram are supported by RTI Connext Micro. Please read the information on the individual types to determine whether a function is supported. | |
Subscription Module | |
Contains the DDS_Subscriber, and DDS_DataReader classes, and more generally, all that is needed on the subscription side. | |
Infrastructure Module | |
Defines the DDS infrastructure package. |
RTI Connext Micro modules following the DDS module definitions.
Information flows with the aid of the following constructs: DDS_Publisher and DDS_DataWriter on the sending side, DDS_Subscriber and DDS_DataReader on the receiving side.
DDS_Topic objects conceptually fit between publications and subscriptions. Publications must be known in such a way that subscriptions can refer to them unambiguously. A DDS_Topic is meant to fulfill that purpose: it associates a name (unique in the domain i.e. the set of applications that are communicating with each other), a data type, and QoS related to the data itself. In addition to the topic QoS, the QoS of the DDS_DataWriter associated with that Topic and the QoS of the DDS_Publisher associated to the DDS_DataWriter control the behavior on the publisher's side, while the corresponding DDS_Topic, DDS_DataReader and DDS_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 DDS_Publisher (or reuse an already created one) and a DDS_DataWriter with all the characteristics of the desired publication. Similarly, when an application wishes to receive data, it must create a DDS_Subscriber (or reuse an already created one) and a DDS_DataReader to define the subscription.
The overall conceptual model is shown below.
Notice that all the main communication objects (the specializations of Entity) follow unified patterns of:
All DCPS entities are attached to a DDS_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.
DDS_DomainEntity is an intermediate object whose only purpose is to state that a DomainParticipant cannot contain other domain participants.
At the DCPS level, data types represent information that is sent atomically. For performance reasons, only plain data structures are handled by this level.
By definition, a DDS_Topic corresponds to a single data type. However, several topics may refer to the same data type. Therefore, a DDS_Topic identifies data of a single type, ranging from one single instance to a whole collection of instances of that given type. This is shown below for the hypothetical data type Foo
.
keys
, can be disseminated on a topic.In case a set of instances is gathered under the same topic, different instances must be distinguishable. This is achieved by means of the values of some data fields that form the key to that data set. The key description (i.e., the list of data fields whose value forms the key) has to be indicated to the middleware. The rule is simple: different data samples with the same key value represent successive values for the same instance, while different data samples with different key values represent different instances. If no key is provided, the data set associated with the DDS_Topic is restricted to a single instance.
Topics need to be known by the middleware and potentially propagated. Topic objects are created using the create operations provided by DDS_DomainParticipant.
The interaction style is straightforward on the publisher's side: when the application decides that it wants to make data available for publication, it calls the appropriate operation on the related DDS_DataWriter (this, in turn, will trigger its DDS_Publisher).
On the subscriber's side however, there are more choices: relevant information may arrive when the application is busy doing something else or when the application is just waiting for that information. Therefore, depending on the way the application is designed, asynchronous notifications or synchronous access may be more appropriate. Both interaction modes are allowed, a DDS_Listener is used to provide a callback for asynchronous access, and polling allows for synchronous access.
DCPS consists of five modules: