The specification divides the complexity of the full data distribution functionality into five profiles (Minimum, Ownership, Content Subscription, Persistence, and Object Model) to help applications meet their individual requirements. The applications can use any or all of the profiles to access the Data Distribution Service. 

DDS Compliance Profiles

The following diagram depicts using a data-oriented approach to solve a typical distributed system problem. The goal in this example is to maintain the temperature in many buildings, using embedded controllers each connected to a number of sensors. Each of these sensors and control processes are connected through a transport mechanism such as Ethernet and use basic protocols such as TCP-UDP/IP to provide standardized communication. 

To achieve data integrity and fail-over capabilities, multiple controllers and sensors are deployed in each building. Controllers within a building collaborate in the process of collecting data from the various sensors. Applications access and manipulate the data through the use of a global data space.

Data-centric technologies such as databases and Service-Oriented Architecture Web service-based applications can interoperate seamlessly with the embedded sensors. These technologies provide a standards-based way for external applications to get, process and manipulate real-time sensor data with out having to know the specifics of the real-time data infrastructure. Furthermore, decoupling the data from the technology that manipulates the data contributes to developing a truly data-centric application. In this example, the external access and monitoring applications can simply receive real-time updates from any sensor as well as issue commands to the various controllers via DDS, SQL, etc., to maintain suitable temperatures. 

For simplicity, this example will focus on the data the sensors send to their controller and how they can be distributed throughout the entire system. The first step in a data-centric approach is to describe the data format carefully in a standards-based way, either IDL or XML, and give it a Topic name. Topics are the element of the DDS middleware publish-subscribe standard which identify the data objects and provide the basic connection between publishers and subscribers. Subscribers (the Controllers in this example) register Topics with the middleware that they wish to receive. Publishers (the individual sensors in this example) register Topics with the middleware that they will send. If the Topics do not match, effective communication does not take place.

Topics enable one to find specific information sources when architecting a loosely coupled system; that is, one which does not know a priori how many sensors or controllers there are going to be or where they all are. The Controller can simply subscribe to TempSensor, the Topic's name, and receive all the sensor updates for that building. Similarly, a sensor does not need to know if it is sending its data to one or multiple Controllers or even an external data store.

Specification of the Topic's name is a key element in a data-centric approach to creating open real-time systems. One could name each sensor's Topic based on its unique location in the building, Floor12Room3Sensor14 for example, but the Controller would then need to be configured every time a sensor is added or removed from the system. Topics (name and type) define the standard interface for the distributed system; chose them appropriately.

Specification of the Topic's data type is equally important as the Topic's name. DDS specifies the use of a subset of the Interface Definition Language (IDL) for specifying a Topic's data type.

Note: IDL readily maps to XML and SQL semantics.

In the definition of the Topic's type, chose one or more data elements to be a Key. Keys provide scalability and the communication infrastructure can use the key to sort and order data from many sensors. In this example, without keys, one would need to create individual Topics for each sensor. Topic names for these topics might be Sensor_1, Sensor_2, and so on. Therefore, even though each Topic is comprised of the same data type, there would still be multiple Topics. With keys, there is only one topic, TempSensor, used to report temperatures.

New sensors can be added without creating a new Topic. The publishing application would just need to set a new id when it was ready to publish. An application can also have a situation where there are multiple publishers of the same Topic with the same key defined. This enables the application to provide redundancy. Per this example, two sensors in the same room using the same Key value will measure the same piece of information. Managing the redundancy, should one or both sensors report to the controller, is accomplished though Quality-of-Service (QoS).

A Domain is the basic DDS construct used to bind individual publications and subscriptions together for communication. A distributed application can elect to use single or multiple DDS Domains for its data-centric communications. A Partition is a way to separate Topics logically within a DDS Domain.

In the context of the example, Partitions can group sensors on different floors. For example, to divide the building into different zones where each zone is controlled by a dedicated Controller, the Sensor and Controller could set the Partition to Floor 1 and Floor 1-6, respectively. The Controller will receive data from all Sensors on Floors 1 through 6. Using Partitions makes it easy to group which Sensors are hooked to a Controller and a Controller can take over a different zone by changing or adding to its Partition list.

In the example, different buildings map to different DDS Domains. Domains isolate communication, promote scalability and segregate different classifications of data.

The following briefly details how one might leverage a few of the DDS QoS Policies for this example.

Ownership

The Ownership QoS specifies whether or not multiple publishers can update the same data object and is how to achieve fault-tolerance using DDS.

Returning to the example, having multiple sensors in the same room and only wanting to get data from the primary (as long as it is functioning), then the Ownership QoS policy is set to Exclusive, stating that only one sensor can update that keyed value. Setting the Ownership QoS value to Shared indicates that there can be multiple sensors in the same room all reporting the same piece of keyed data. In this case the Controller would get all updates from all sensors and treat the values as the same measurement.

Durability

The Durability QoS specifies whether past samples of data will be available to newly joining subscribers.

Considering the example, if a Controller were to reboot, rather than require all sensors to resend their data, or require the data to be sent at a periodic rate in case the systems reboots, one simply gets the latest published value for every attached sensor. This effectively decouples the system in time and provides a high degree of data integrity.

History

History specifies how many data samples are stored for later delivery.

In the case of the example, a rebooted controller may want the last 5 samples from its sensors, so that it can make sure that readings are consistent.

Reliability

The Reliability QoS may be set on a per Topic basis and informs the middleware that the Subscription should receive all data (no missed samples) from a Publication even over non-reliable transports. Generally for periodic publications Reliability doesn't need to be set, since it can just get the updated value one sample period later. Although periodic sensor data doesn't need to be delivered reliably, synchronization commands between Controllers in this example could be.

This simply stated example is surprisingly complex, containing many elements of real-time messaging, data integrity and failover capabilities, integration with databases, web services, as well as scalability and modularity concerns while remaining data-centric.

• Decoupling Using DDS and Publish-Subscribe
• DDS Quality of Service
• DDS Data-Centric Publish-Subscribe (DCPS)
• DDS Data Local Reconstruction Layer (DLRL)