Embedded Systems
OMG's Data Distribution Service Standard
By Rajive Joshi and Gerardo Pardo,Castellote, November 20, 2006
The OMG Data Distribution Service (DDS) Standard specifies a mandatory API for data-centric publish-subscribe
Tuning the Quality of Service
The QoSPolicy settings available on the DataReader and DataWriter objects can be used to fine tune characteristics of the data flow between them. The default policies are tuned to the desired settings, and may be specified the time of DataWriter/DataReader creation or later via the get_qos()/set_qos() operations.
For example, periodic DataWriters can indicate the rate at which they can publish by offering guaranteed update deadlines via the "Deadline" QoSPolicy. By setting a deadline, a compliant DataWriter promises to send a new update at a minimum rate. DataReaders may then request data at that or any slower rate via the TimeBasedFilter QosPolicy. DataReaders can also specify a deadline for receiving the next sample update. If the deadline is missed, the the middleware can notify a listener installed by the application.
DataWriters may offer levels of reliability (via the Reliability QoSPolicy), parameterized by the number of past issues they can store to retry transmissions (via the History QoSPolicy). DataReaders may request differing levels of reliable delivery, ranging from fast-but-unreliable "best efforts" to highly reliable in-order delivery. This provides per-data-flow reliability control.
Figure 9: Under exclusive ownership a Topic channel can only be updated by a single DataWriter, the one with the highest ownership-strength S.
The middleware can automatically arbitrate between multiple DataWriters of the same Topic as specified by the Ownership and OwnershipStrength QosPolicies (Figure 9). Under exclusive ownership, a channel in a Topic can only be updated by a single DataWriter. DataReaders receive from the highest ownership-strength active DataWriter. This provides automatic fail-over; if a strong DataWriter fails, all DataReaders immediately receive updates from the backup (weaker) DataWriter. A DataWriter can also specify duration after which a sample should be considered stale via the "Lifespan" QosPolicy (Figure 10).
Figure 10: The Lifespan QoS Policy specifies the duration after which a received data sample should be considered stale, and discarded by the middleware.
DataWriters can specify how long previously published data is saved via the Durability QosPolicy. Late-joining DataReaders to durable DataWriters can then be automatically updated with past values by the DDS middleware.
The DDS specification defines many more QosPolicies. The behavior of each entity can be tuned on a per entity instance basis (Figure 4).