The elevator pitch for Data Distribution Services
Do you have a project with components exchanging data across a network over different operating systems, micro controllers and programming languages?
Do the components have to work well together in a coherent, decoupled way?
Then Data Distribution Services could be for you.
Data Distribution Services (DDS) is an interoperable, scalable middleware for data exchange using the publisher–subscriber pattern managed by the Object Management Group (OMG) . The publisher–subscriber pattern has the advantage that it decouples the structure of data from the specific implementation of each of the components. Data Distribution Services is useful for applications that require interoperability between operating systems, platforms and programming languages. DDS is used in medical, military and automotive instustries amongst others.
Interoperability
DDS allows programs from different vendors platforms and languages to exchange information. Platforms commonly supported : Linux, Windows. Microcontrollers, MacOS, Android, iOS. Languages commonly supported : C++, Dot Net C#, Java, C, Python.
Here are some popular and well supported implementations of DDS and their relative advantages and disadvantages, there are many others you can look up in the DDS foundation link below.
- RTI : Well developed and expensive but very good support and tooling.
- Open Splice : Also well developed with an open source version.
- Twin Oaks : Microprocessor centric, well supported, tooling not as sophisticated as the others.
Publish subscribe pattern
Publish–subscribe is a messaging pattern where publishers, do not send the messages (referred to as samples) directly to specific subscribers, but instead publish samples to DDS. Similarly, subscribers express interest in one or more message types (referred to as topics) and only receive subscribed topics, without direct knowledge of a specific publisher or publishers. Once a publisher decides that the subscriber has to be called a listener can call code to handle the sample. The conditions under which the subscriber is called depends on the QoS (Quality of service).
High level view of data distribution services.
Work flow during project iterations
The interface is derived from the requirements. This is codified into IDL and QoS that is reviewed with the interface description documents. The IDL can be used as input to the vendor and platform and language specific code generators to create the boiler plate code for the topics. (if the vendor tooling supports this).
High level view of data distribution services interface definition and code generation.
Interface Description Language (IDL)
An interface description language or interface definition language (IDL), is a generic term for a language that lets a program or object written in one language communicate with another program written in an unknown language. IDLs describe an interface in a language-independent way, enabling communication between software components that do not share a language, for example, between those written in C++ and those written in Java.
Example of simple IDL
struct WeatherItem{
long Elevation;
long Temperature;
};
struct Weather {
string<64> Location;
long sampleId;
sequence<WeatherItem, 127> WeatherProfile;
};
Quality of service (QoS)
Quality of service in the context of DDS is how the message is sent. Is the sample send periodically without regard to any changes or is it only sent on change. Do you want the sample to be valid 2 seconds after it is written or for ever. Is the current sample the last sample sent of or the last sample received. Various vendors have different methods of specifying or changing the QoS. The most flexible is in a configuration file. Another advantage of this method of specifying the QoS is that it can be used to mitigate issues without changing the code and is treated differently in the Quality control Process.
Below is an example of a simple QoS configuration file to give you some idea of how this can be specified.
Here is a brief description of some terms in this QoS.
Reliable : An attempt will be made to send all samples in the history.
Keep all history : An attempt to keep all samples the until they are taken by the subscriber will be made.
<?xml version="1.0"?>
<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://community.rti.com/schema/6.1.0/rti_dds_qos_profiles.xsd">
<qos_library name="Weather_Library">
<qos_profile name="Weather_Profile" is_default_qos="true">
<datawriter_qos>
<reliability>
<kind>RELIABLE_RELIABILITY_QOS</kind>
</reliability>
<history>
<kind>KEEP_ALL_HISTORY_QOS</kind>
</history>
</datawriter_qos>
<datareader_qos>
<reliability>
<kind>RELIABLE_RELIABILITY_QOS</kind>
</reliability>
<history>
<kind>KEEP_ALL_HISTORY_QOS</kind>
</history>
</datareader_qos>
<domain_participant_qos>
<participant_name>
<name>WeatherData</name>
</participant_name>
</domain_participant_qos>
</qos_profile>
</qos_library>
</dds>
Summary
DDS is a useful standard to put structure into the communication between components of a software system. It has the advantage of decoupling the data schema from the applications. How the data is transported from the publishers to the subscribers can be specified via configuration in some implementations. This can be of great benefit to developers in the quality control process. It is available for a number of platforms and languages, this makes it a good fit for IOT projects.
