Applying the Data Distribution Service in an IoT Healthcare System

In my last post, I described how the Data Distribution Service (DDS) standard is used to provide ubiquitous access to clinical measurements. In this post, I will be introducing the foundations of this enabling technology that can allow healthcare systems to reap the full potential of the Internet of Things.

The abstraction at the foundation of DDS is a global data space. Think of it as the virtual area where data on a patient is going to be gathered, shared, analyzed and acted upon. DDS applications—sensors, devices, applications, etc.—autonomously, anonymously, securely and efficiently cooperate by reading and writing Topics on this global data space – where a unique name, a type and a set of qualities of service (QoS) identify a Topic. Applications that join the global data space automatically discover their mutual existence as well as their interest (i.e. Topics produced and consumed). This information is then used to optimize the protocol and communication path used for efficient and high performance data sharing.

Conceptually the global data space is active, in the sense that it can retain data for late joiners and make it available even if the producer is no longer available. For example, a doctor can take advantage of this feature to see the history of clinical measurements produced by a given device. This feature is commonly called temporal decoupling as the producer and the consumer don’t need to be running at the same time in order to share data.

DDS’ global data space implementations are required to be fully distributed – no single point of failure or single point of bottleneck. This makes it possible for DDS-based system to scale out well and to experience very low latencies and high throughput. As an example, on contemporary hardware connected by a 1 Gbps Ethernet network, DDS has an inter-node latency of ~30 usec and can easily distributed several millions samples per second.

Anatomy of a DDS Application
Structurally a DDS application is composed by different entities (see picture below). The DomainParticipant provide access to a DDS domain. A domain represents a global data space instance and is identified by a natural number, 0, 1, 2, …, n. A domain can be further organized into partitions – partitions are used to organize data within the domain. Publishers and Subscribers control access to the partitions. Finally, the DataWriter and DataReader are used by applications to write and read data into the partitions associated with their respective Publisher and Subscriber.

As DDS is independent of the programming language and hardware and software platform, it allows applications written in different languages and deployed on different OS to exchange data – in other terms DDS takes care of representing data in a programming language and hardware independent manner, dealing with endianness and data layout. This means that a device developed using C++ and running Linux on an ARM processor is going to be able to send and receive data from a device developed using C# and running Windows Embedded on an x86 processor—and it won’t matter if the devices are in the same room, same facility, same state or same country.

Understanding DDS Topics
As I mentioned before, DDS uses Topics to represent the information shared between applications. So far, I’ve told you that a Topic has (1) a unique name, (2) a type used to represent the information associated with the Topic in a programming language, and (3) a set of qualities of service – but there is more. Topic can be keyed or keyless. When available, they key is used to identify a specific topic instances. Let’s try to understand this with an example. Imagine that we want to make available on DDS the data produced by an oxymeter. In this case the first thing we need to decide is how to model the data with a Topic type. Below you see the Topic type that may represent the information provided by a hypothetical oxymeter. The topic type is defined using IDL, but XML or Java could also be used.

struct Oxymetry {
string deviceId;
long spO2;
long bpm;
long pleth;
#pragma keylist Oximetry deviceId

Notice that with the #pragma directive I’ve defined the attribute deviceId as the key for the type. This attribute allows to uniquely identifying the device that produces the data. In DDS terms, each unique value of the deviceId attribute identifies a Topic instance. DDS provides specific life cycle information associated to instances, such as informing you when a new instance is available as well as when is no more in the system. When Topic instances are tied to device, the life-cycle management is particularly useful in learning about the operational status of the device itself.

The values assumed by a specific instance are called samples. Thus, DDS applications write samples belonging to an instance of a specific topic.

Reading and Writing Data
As mentioned above, in DDS data is read and written using DataWriter and DataReader. Specifically, a Datareader will receive in its local cache (a local projection of the global data space) the data written by the DataWriter if the two match. A Datareader and a DataWriter match if they have been defined for the same Topic and with compatible QoS. The set of data received by a Datareader can be controlled through content filters. Content filters are expressions defined with SQL WHERE syntax that predicate Topic attributes. For instance, the filter expression “spO2 < 85” could be used to receive the oxymeter data only when the saturation is below 85percent.

Quality of Service
DDS provides 22 Quality of Service policies that give very fine control over local resource, network utilization, traffic prioritization, and data management. For the complete list refer to the DDS Tutorial.

Your First DDS-Based Pulse Oxymeter
At this point we are ready to write our first oxymeter application. We will write the application that would run on the device and also another application that would display the readings on the console. Below I’ll provide you with the C++ code, but you can also check the Java and Scala version online.

int main(int argc, char* argv[]) {
if (argc < 2) {
std::cout << “USAGE:\n\t oxymeter <device-id>” << std::endl;
return 1;

std::string deviceId(argv[1]);
DomainParticipant dp(0);
Topic<Oxymetry> topic(dp, “TOxymetry”);
Publisher pub(dp);

DataWriter<Oxymetry> dw(dp, topic);

// isActive() becomes false when the device is turning off.
while (isActive()) {
auto o = get_oximetry(deviceId);
// write data
return 0;

int main(int argc, char* argv[]) {
DomainParticipant dp(0);
Topic<Oxymetry> topic(dp, “TOxymetry”);
Subscriber sub(dp);

DataReader<Oxymetry> dr(dp, topic);

// Create the waitset
WaitSet ws;
// Create a ReadCondition for our data reader
// and configure it for new data
ReadCondition rc(dr, DataState::new_data());
// attache the condition
ws += rc;

while (true) {
auto samples =;

[](const dds::sub::Sample<Oxymetry>& s) {
std::cout << << std::endl;
return 0;

This example reveals how simple is to use DDS to share data. Beside the simplicity, as explained in my last blog post, once in DDS, the data can be made available across any device and shared at any scale. DDS-based platforms such as PrismTech’s Vortex provide a good example of how this can be done.

If you want to learn more about DDS, feel free to read the DDS Tutorial or check out the various educational slides.

Building the Internet of Things with DDS

The real value of the () and the () is ubiquitous information availability and consequently the decisions that can be made from it. The importance of ubiquitous data availability has significantly elevated attention on standards-based data sharing technologies. In this post, I’ll analyze the data sharing requirement characteristics of IoT/I2 systems and describe how the Object Management Group (OMG) Data Distribution Service (DDS) standard ideally addresses them.

Data sharing in IoT/I2

Data sharing patterns within IoT/I2 systems can be classified as follows:

Device-2-Device. This communication pattern is prevalent on edge systems where devices or traditional computing systems need to efficiently share data, such as plants, vehicles, mobile devices, etc. Device-2-Device data sharing is facilitated by broker-less peer-to-peer infrastructures that simplify deployment, foster fault-tolerant, and provide performance-sensitive applications with low latency and high throughput.

Device-2-. Individual devices and subsystems interact with cloud services and applications for mediating data sharing as well as for data collection and analytics. The Device-2-Cloud communication can have wildly different needs depending on the application and the kind of data being shared. For instance, a remote surgery application has far more stringent temporal requirements than a application. On the other hand, the smart city application may have more stringent requirements with respect to efficient network and energy management of the device. Thus depending on the use case, Device-2-Cloud communication has to be able to support high-throughput and low-latency data exchanges as well as operation over bandwidth constrained links. Support for intermittent connectivity and variable latency link is also quite important.

Cloud-2-Cloud. Although few systems are currently being deployed to span across multiple instances or multiple IaaS regions (such as deploying across EC2 EU and U.S. regions), it will be increasingly important to be able to easily and efficiently exchange data across cloud “domains.” In this case, the data sharing technology needs to support smart routing to ensure that the best path is always taken to distribute data, provide high throughput, and deliver low per-message overhead.

Besides the data sharing patterns identified above, there are crosscutting concerns that a data distribution technology needs to properly address, such as platform independence – for example, the ability to run on embedded, mobile, enterprise and cloud apps, and security.

The (DDS)

The DDS is an OMG standard for seamless, ubiquitous, efficient, timely, and secure data sharing – independent from the hardware and the software platform. DDS defines a wire protocol that allows for multiple vendor implementations to interoperate as well as an API that eases application porting across vendor products. The standard requires the implementation to be fully distributed and broker-less, meaning that the DDS application can communicate without any mediation, yet when useful, DDS communication can be transparently brokered.

The basic abstraction at the foundation of DDS is that of a Topic. A Topic captures the information to be shared along with the Quality of Service associated with it. This way it is possible to control the functional and non-functional properties of data sharing. DDS provides a rich set of QoS policies that control local resource usage, network utilization, traffic differentiation, and data availability for late joiners. In DDS the production of data is performed through Data Writers while the data consumption is through Data Readers. For a given Topic, Data Readers can further refine the information received through content and temporal filters. DDS is also equipped with a dynamic discovery service that allows the application to dynamically discover the information available in the system and match the relevant sources. Finally, the DDS Security standard provides an extensible framework for dealing with authentication, encryption, and access control.

Applying DDS to IoT and I2

Among the standards identified as relevant by the Industrial Internet Consortium for IoT and I2 systems, DDS is the one that stands out with respect to the breath and depth of coverage of IoT/I2 data sharing requirements. Let’s see what DDS has that make it so special.

Device-2-Device. DDS provides a very efficient and scalable platform for Device-2-Device communication. DDS implementation can be scaled down to deeply embedded devices or up to high-end machines. A top-performing DDS implementation, such as PrismTech‘s intelligent data sharing platform, Vortex, which can offer latency as low as ~30 usec on Gbps Ethernet networks and point-to-point throughput of several million messages per second. DDS features a binary and efficient wire-protocol that makes it a viable solution also for Device-2-Device communication in network-constrained environments. The broker-less and peer-to-peer nature of DDS makes it an ideal choice for Device-2-Device communication. The ability to transparently broker DDS communication – especially when devices communicate through multicast – eases the integration of subsystems into IoT and I2 systems.

Device-2-Cloud. DDS supports multiple transport protocols, such as UDP/IP and TCP/IP, and when available can also take advantage of multicast. UDP/IP support is extremely useful in applications that deal with interactive, soft real-time data in situations when TCP/IP introduces either too much overhead or head-of-line blocking issues. For deployment that can’t take advantage of UDP/IP, DDS alleviates the problems introduced by TCP/IP vis-á-vis head-of-line blocking. This is done through its support for traffic differentiation and prioritization along with selective down-sampling. Independent of the transport used, DDS supports three different kinds of reliability: best effort, last value reliability, and reliability. Of these three, only the latter behaves like “TCP/IP reliability.” The others allow DDS to drop samples to ensure that stale data does not delay new data.

The efficient wire-protocol, in combination with the rich transport and reliability semantics support, make DDS an excellent choice for sharing both periodic data, such as telemetry, as well as data requiring high reliability. In addition, the built-in support for content filtering ensures that data is only sent if there are consumers that share the same interest and whose filter matches the data being produced.

Cloud-2-Cloud. The high throughput and low latency that can be delivered by DDS makes it a perfect choice for data sharing across the big pipes connecting various data centers.

In summary, DDS is the standard that ideally addresses most of the requirements of IoT/I2 systems. DDS-based platforms, such as PrismTech’s Vortex, provide device solutions for mobile, embedded, web, enterprise, and cloud applications along with cloud messaging implementations. DDS-based solutions are currently deployed today in smart cities, smart grids, smart transportation, finance, and healthcare environments.

If you want learn more about DDS check out this tutorial or the many educational slides freely available on SlideShare.

Unleashing Clinical Measurements

Medical devices are an essential element of modern medicine as they provide accurate clinical measurements such as oxygen saturation, blood pressure and temperature, x-ray and ultrasound imaging, as well as automatically administer intravenous medications, and provide support of critical life functions. In spite of the advances toward improving medical devices’ accuracy, robustness and reducing their form factor, very little has been done to pursue interoperability – most medical devices communicate their measurements through proprietary data formats and protocols thus hindering the integration with other medical systems.

This lack of seamless integration has several negative clinical implications. As an example, the use of a single clinical measurement – oxygen saturation – makes it harder than it should to detect morphine narcolepsy false positives. As the oxygen saturation measurement is very sensible to the proper positioning of the probe, several false positive can be raised in patients that are restless, perhaps due to post-operatory pain.

If multiple clinical measurements, such as breath per seconds, oxygen saturation and perhaps heartbeats, were fused together to detect morphine narcolepsy, then the number of false positives could be dramatically reduced. In addition, the actual insurgence of a narcolepsy could be detected earlier.

Ideally, medical devices should make available their measurements using a standard data model and through an open and standard protocol. The good news is that we have been working for the past year with the MDPnP (Medical Device Plug-and-Play) – a consortium of hospitals, research centers and medical device manufacturers – to explore the use of the OMG Data Distribution Service as the standard for sharing clinical data. In addition, we along with a number of the MDPnP participants have been involved with the SmartAmerica Challenge, a White House Presidential Innovation Fellows project designed to showcase Internet of Things frameworks and benefits for a variety of environments including healthcare.

DDS enables seamless, efficient and secure information sharing across any device and at any scale. As a result, once the clinical data is made available over DDS, it can be consumed virtually anywhere, on anything, and by anybody who has the proper access rights. The simple fact of making data available through DDS enables a series of use cases that are very valuable in supporting both doctors as well as patients.

Read: Applying the Data Distribution Service in an IoT Healthcare System

As an example, if we consider the image below, we see how a DDS-based platform, namely PrismTech’s Vortex, is currently being used to allow doctors to access patient data from anywhere as well as non-hospitalized patient to be continuously monitored.

Specifically, in this use case DDS makes it possible for doctors to enter a hospital room and discover the devices that are available. Doctors can then select one or more devices from which they would like to see live measurements. In case the doctors need to discuss the live data with colleagues from another hospital, the clinical data will be shipped in real-time to the remote doctors on whichever devices they have at hand–a mobile, a tablet or a notebook. In addition, data is continuously streamed to a private cloud where on-line as well as off-line analytics are executed on the various medical measurements.

Likewise, mobile personal medical devices can also make their data available seamlessly to doctors as well as to analytics applications. For instance, consider an elderly patient suffering from dyspnea. This patient can be continuously monitored while staying comfortably at home thanks to the use of a mobile oxymeter. This oxymeter would be sending data to the hospital’s private cloud via 3G/4G or WiFi where analytics applications interpret the data and respond as necessary. For example, if it’s detected that the patient needs some oxygen, a notification can go out to the patient while an alert is sent the doctor.

The beauty of DDS is that each of these use cases is seamlessly supported by its core abstraction: ubiquitous data sharing. Additionally, DDS supports for data modeling and QoS facilitates the definition of common data models for medical devices. The combination of standard data models and interoperable protocol are key elements to enable medical devices interoperability.

If you want to learn more about the DDS standard you can refer to the OMG website where you can find the specification or take a look at the educational material available on SlideShare.

The Adoption of Operational Technologies in Simulation

Simulation and Operational Technologies have historically evolved in isolation and with very little cross-fertilization. This has led to a divergence of technologies and skills along with the necessity for ad hoc integration of simulation and operational systems.

This situation is rapidly changing due to a convergence of the simulation community towards operational technologies such as the Object Management Group’s (OMG) Data Distribution Service for Real-Time Systems (DDS). In this blog post I will summarize the motivations behind this convergence and provide quantitative indications, when data is available, of the induced benefits.

Performance and Scalability. Simulation technologies such as High Level Architecture (HLA), Distributed Interactive Simulation (DIS), Test and Training Enabling Architecture (TENA) have proven to be the bottleneck when building advanced real-time simulations or large-scale simulations. Performance and scalability is one of the top reasons why several simulation groups across large systems integrators, as well as companies specializing in simulation, have adopted DDS as their underlying data bus.  Performance improvements have been measured up to a factor 2x while through adopting the DDS fully distributed architecture they have achieved linear scalability!

Integration with Operational Systems. With the rising importance of co-simulation it becomes critical that simulations and operational systems can seamlessly interact. This means two things. First, it should be possible to  “inter-connect” the simulated and the real systems without having to develop specific adaptors. Second, the simulated system should  “keep the pace” of the operational system. As DDS is a mandated standard for several operational systems, the convergence towards DDS eliminates the need for bridging – thus eliminating the cost of integration. In addition this convergence provides users with a level of performance that is compatible with operational systems and a plug-and-play co-simulation architecture.

Market and Vendors. The operational technology market is bigger and more competitive than the simulation market, as such it provides higher quality technology at more modest prices when compared with the niche simulation market. In addition the number of vendors of DDS along with the number of Open Source offerings surpasses by several times that of a typical simulation standard or technology. This competitive scenario is thus more favorable to the user (please refer to the Porter Five Forces Scheme as it increases bargaining power and lowers the overall cost of software procurement throughout its lifetime. In addition, the competitive landscape means that vendors need to continually innovate in order to gain market share thus providing end-users with top-notch technologies and tools.

Skills and Productivity. Another important reason why companies are converging toward Operational Technologies is because it is easier for them to find and retain competent engineers as well as to more easily reassign their workforce. In addition, operational technologies such as DDS have proven to improve the productivity, over technologies such as HLA, by 2-3x for just the development phase.

For those interested in some futher technical details, the following resources are are available:


DDS Web Programming with dscript

In the past few months I have had quite a few animated discussions with members of the Data Distribution Service (DDS) community (read other vendors) with respect to the kind of “Web” integration we should provide for DDS. Looking at the trend on HTML5/JavaScript clients for me it was a no-brainer that our focus should have been on providing two things:

  • A simple DDS abstraction to allow JavaScript programmers to do Publish / Subscribe (Pub/Sub) from the browser (or Node.js).
  • A seamless integration between web client and native DDS clients.

Hard to believe… I was the voice out of the choir. The rest of the crowd seamed to believe, or had some obscure interest to believe, that what really mattered was to provide DDS with a W3C WebService API. Yack! The result of this is a Web-Enabled recommended (not yet adopted) OMG specification that actually has nothing to do with the Web (other than with heavy weight old fashioned Web Services). In essence the end result was more a “Web-Disabled” DDS.

So what to do? Well, if you know me, you’ve already guessed. As I did with simd-cxx for the DDS C++ API I’ve created a prototype of what the real Web-DDS technology should be like. After some fun hacking I am happy to unveil dscript.

I’ve posted an intro presentation on slideshare, but I’ll try to summarize the key points of dscript below.

dscript is composed by two elements:

  • Client Side (dscript.js): JavaScript/CoffeeScript framework that provides DDS-like abstractions
  • Server Side ( A Router that transparently bridges data between matching DDS entities, e.g. Browser-2-Browser, DDS-2-Browser and Browser-2-DDS

Dscript diagram

The client side provides a simplified and refined semantics for the DDS entities, for instance dscript reduces the DDS concepts to Topics, DataReaders, DataWriters and QoS — DomainParticipant and Publishers are managed for you.

The API is reactive and considers DataReaders as the source for a stream of data. This data can be handled by the application or bound to a data cache (notice the cache is not part of the DataReader) that provides a higher order function for processing contained data.

The server side minimizes the number of DataReader / DataWriter created to manage the established sessions and deals with entity garbage collection too.

Enough talking, let me show you some code that actually publishes some data:

Dscript code

And here is some code that consumes data:

Dscript code consumes

Pretty Cool, isn’t it? The good news is that dscript.js and are Open Source projects available on GitHub.

Good Hacking!


OpenSplice Mobile – DDS has never been so much fun

Today we have released OpenSplice Mobile v1.1 and, as I’ll describe in this post, it brings DDS to a new level of usability and coolness!

To begin with, OpenSplice Mobile is a pure-Java implementation of DDS, meaning that you can run it on anything that has a Java VM, an embedded Java VM, or an Android VM. In essence, you can run OpenSplice Mobile on your Android phone / tablet, on your Raspberry Pi, on your Panda Board, etc., or simply on a more traditional computing platform, e.g. a server, a workstation or laptop. BTW, I have actually already demonstrated this as some of you may have seen at the Berlin OpenSplice User Meeting a couple of weeks ago.

At this point you may wonder how the same DDS implementation may be a good fit for both resource constrained embedded devices as well as high-end servers with multiple cores — the trick is OpenSplice Mobile SEDA (Staged Event Driven Architecture). By configuring the stages in the SEDA you can optimize OpenSplice Mobile for latency and embedded devices or for throughput and high-end servers. The configuration can be controlled via a property file or a series of “-D” options for the JVM.

Those of you that can’t wait to start hacking with OpenSplice Mobile, will be happy to know that it provides the new Java 5 API for DDS. This new API removes quite a bit of nonsense of the previous Java API and enforces a disciplined class loading — in essence you can control the class loader that will be loading classes for the DDS types. If that was not enough to wet your appetite, we have added a few cool features such as the ability to express queries and filters using Java and JavaScript.  This means that to query/filter DDS data you are not limited to what can be expressed by the WHERE clause of a SQL statement, you have the power of a predicate written in Java or in JavaScript! If you wonder about lambdas, we will obviously add support for the JDK8 version, yet at the present time OpenSplice Mobile requires a JDK6.

At this point , assuming you’ve written your first OpenSplice Mobile application and you would like to see its runtime structure —  you’d love to explore the jungle of DDS entities. How can you do that? OpenSplice Mobile has a Monitor that gives access to all information concerning the DDS entities as well as the protocol entities. With the Monitor you can browse DDS entities, verify QoS settings, check the status of reliability queues etc. (see snapshot below). If you have looked at the Mobile distribution you may wonder how you start it. Things could not be any simpler, you just have to make sure that the monitor Jar is in the Java classpath and then simply point your browser to http://localhost:8080 (or the URL of the machine where you want to inspect the DDS app). If the port 8080 is taken the monitor will automatically take the first free, e.g. 8081, or 8082 etc.

OpenSplice Mobile Graphic

Now, if you have not done so already, go and get OpenSplice Mobile from our Software Downloads and start hacking some code!

Good Hacking,

P.S. If you want to play with the OpenSplice Mobile iShapes application on your Android device you can get it from the Google Play Store

The OpenSplice Community Edition v6.3 is Coming

I’m really pleased to announce that our very latest OpenSplice code base (v6.3) will be made available to the Open Source community on July 8 2013.

OpenSplice Community Edition v6.3 features many innovations and improvements:

  • DDS ISO C++ API: The DDS ISO C++ API is the new standard API for programming DDS applications in C++. This new API immensely improves usability, safety and efficiency along with feeling far more idiomatic to a C++ programmer. It is important to say that the DDS ISO C++ API draws most of its concepts from two Open Source projects that we have been running, namely simd-cxx ( and Escalier  (
  • Standalone Deployment. OpenSplice Community v6.3 introduces support for the stand-alone deployment mode which along with the latest DDSI v2.1 implementation, enabling a greatly enhanced ‘zero-configuration’ out-of-the-box experience.
  • Fixes and Improvements. Numerous improvements and updates have been made to the code base since OpenSplice v5.5 (the previous Community Edition release), including performance, footprint, robustness as well as  several bug fixes.

The FAQs available at should hopefully answer most of the questions about the new Community Edition release.

A Webcast covering the details of the release will be presented on July 30 2013.  To register for the Webcast please visit

Mark the July 8 2013 on your calendar and happy hacking with the new OpenSplice Community – I am sure you’ll love it!