I can't believe I have been at RTI for more than 12 years now! In that time, I have seen the evolution of the OMG Data Distribution Service from its early days, as well as the realization of RTI's mission to create the best DDS implementation available.
During our history with DDS, we have come across applications that could only support very low memory resources. It may seem remarkable today to field a system with less than 8 MB of RAM, but we have seen application requirements that specify far less memory than that. A while back we set out to create a version of DDS for resource-limited devices. We call it RTI Connext DDS Micro and we have built it into applications with under 128 K of RAM. We're pretty excited about that!
To achieve this capability, Connext DDS Micro supports a subset of the functionality of a complete Connext DDS implementation. I would estimate the level of functionality to be around 80% of the standard DDS product we provide. Within this 80%, we support critical capabilities like reliability, keys/instances, liveliness, durability, and so on. And because we preserved the RTPS (Real Time Publish Subscribe) wire format protocol, DDS Micro applications can communicate with regular DDS applications and visa versa.
As I mentioned above, in order to reduce RAM usage, we had to make a few sacrifices along the way. One of the features we eliminated was the ability for a participant to send out data type information on discovery. This feature is an optional part of the RTPS protocol and is in use today, when enabled, by regular DDS participants. In fact, this is a key feature we rely on when using our tools with DDS applications. For example, our Admin Console was upgraded last year with the ability to visualize data directly within the tool. This means that the Admin Console tool is now able to subscribe directly to data being published by DDS applications. You can see the Admin Console data visualization tools in action here: overview & deep dive.
When this feature first came out, it relied on the ability of DDS participants to share data type information on discovery. Once learning of the data type, and creating a subscription to the topic using that data type, Admin Console could display live data as it was being published. Here is an example of Admin Console displaying a patient heartbeat waveform published by a DDS application:
This is a great feature that many developers of DDS applications leverage today. However, it cannot be used with DDS Micro applications because these applications do not send out data type information on discovery.
To fix this limitation, our great tools team added a new capability within Admin Console. Instead of relying solely on data type information being sent out on discovery, the Admin Console now has the ability to configure a data type directly into the tool using an XML file to describe the data type or set of data types. When subscribing to a topic within Admin Console, you can now source in an XML file, as seen in this screenshot:
Once you pull up the subscribe function, you have the option to "Load Data Types from XML file." From there you can select an XML file:
The content of the XML file is basically a description of the FunctionGeneratorType as shown below:
Then, with the correct data type information loaded, Admin Console is able to subscribe to the publisher.
In the following example, the DDS Micro publisher is a simple Function Generator publisher that sends out streaming sensor data and emits sine wave, square wave, and triangle wave data. Here is the visualization of that streaming DDS Micro publisher.
I have to say, it's great being here at RTI to see all of these capabilities come together to provide a platform for the Industrial Internet of Things. I can't wait to see the innovations coming in the future for enabling even more devices to share their data.