High Level Data-Centric Interfaces Replace Message-Centric Programming
The main goal of DDS is to share the right data at the right place at the right time, even between time-decoupled publishers and consumers. DDS implements global data space by carefully replicating relevant portions of the logically shared dataspace.
The Right Data
Not all data needs to be everywhere. Middleware should only deliver the data that consumers really need. Interest-based filtering can apply to both content and data rates. With proper implementation, DDS saves bandwidth and processing power, and minimizes overall application complexity.
As a data-centric solution, DDS can understand the schema of the shared data. This allows it to filter on content, age and/or lifecycle to provide applications with only the data they need. For example, you can send only boiler temperatures over 300 (content filter) with at most ten updates per second (rate). This efficient approach can often save 90% of the data communications overhead in many systems.
The Right Place
Data must be available where it is needed, to facilitate self-forming systems. DDS distributes and maintains data so it is readily available.
DDS dynamically discovers publishers and subscribers, the data types they want to share, and the related Quality-of-Service (QoS). Following a successful match, DDS enforces timely distribution according to the QoS. It implements a QoS-enforced logical channel for each data stream between each publisher-subscriber pair. A DDS subscriber can be sure that its peer publisher is actually alive and that any data produced will be delivered. This greatly simplifies application development and error handling.
The Right Time
Real-time systems interact with the real world. Data must be available on time – the right data too late is a failure. Data differ in priority, reliability, timing, and other non-functional properties. DDS balances utilization of scarce resources to distribute data at the right time.
DDS middleware uses logical QoS policies, as set by the applications at runtime, to balance efficiency and determinism. The QoS contracts ensure these timing relationships. For example, if a subscriber requires an update every 10ms and its matched publisher does not deliver, the system declares an error, enabling remedial action. QoS policies cover many characteristics, including urgency, importance, reliability, persistence, and liveliness.
Underlying Technical Concepts
- Relational data modeling: DDS addresses data in a manner similar to relational databases. It can manage data by both structure related topics (using key-fields) and allow ad-hoc queries and filters on content and time so applications can extract specific data as needed.
- Pub-sub messaging: DDS uses the publish/subscribe paradigm for dynamic discovery and primary management of data-flows between relevant DDS entities, including publishers, subscribers, durability services, recording and replay-services, and connected databases. Request-reply and other patterns are built on this powerful substrate.
- Reliable multicast: The DDS standard wire protocol implements reliable multicast over plain UDP sockets, allowing systems to efficiently benefit from modern networking infrastructures.
- Lifecycle awareness: Unlike message-centric products, DDS offers explicit application support for information lifecycle awareness. For instance, it detects, communicates, and informs applications about first and last appearances of data (topic instance) updates. This facilitates timely responses to new and outdated information.
- Trigger patterns: DDS offers a variety of trigger patterns that follow updates on subscribed information. Examples include polling, callbacks (typical for GUIs), and WaitSets (similar to Unix ‘select,’ to provide full application control for prioritized handling of selective trigger events).
For additional details and technical diagrams, please refer to the ‘What is DDS’ section.