<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=135637837074656&amp;ev=PageView&amp;noscript=1">

MQTT and DDS for M2M: Disparate Approaches to the Internet of Things

May 8, 2013 by
|

The Internet of Things (IoT) has been getting a lot of attention lately. The impetus behind some of this is the recent announcement of an OASIS initiative to standardize the IBM MQTT protocol as a means for “Things” to communicate. This New York Times blog post provides some background on MQTT and the announcement.

If MQTT gives you a sense of déjà vu, then you’re likely familiar with the Object Management Group (OMG) Data Distribution Service for Real-Time Systems (DDS) standard. Like MQTT, DDS was designed specifically to address machine-to-machine (M2M) communication, the foundation for the IoT.

However, while they may share common aspirations, MQTT and DDS are very different standards. Each is optimized around different assumptions about how the IoT will be composed:

  • MQTT is optimized for centralized data collection and analysis – connecting sensors and mobile devices to applications running in a data center.
  • DDS is optimized for distributed processing – directly connecting sensors, devices and applications to each other without any dependence on centralized IT infrastructure.

The differences between MQTT and DDS are manifest in their underlying architectures.

MQTT is hub-and-spoke. Sensors, devices and applications communicate through a message broker running on a server (or appliance) in a data center. All communication routes through this centralized broker.

DDS is decentralized. Things that produce data communicate directly with the applications and Things that consume that data. In other words, peer-to-peer. Data only flows to a data center if it’s required in the data center.

Because of their different architectures, MQTT and DDS are suited for different types of applications.

MQTT accommodates classic M2M applications, in which a client machine talks to a server machine, one-to-one. An example is remote asset monitoring, such as sensors that monitor oil wells and pipelines.

DDS is best when not all data processing is centralized. For example, consider a patient monitoring system. Sensor data (such as vital statistics) is needed bedside, at a nurse’s station, for electronic health records and even on a physician’s mobile device. It would be incredibly inefficient to route sensor data through a data center to get it to a co-located bedside monitor. It may even be technically untenable due to the aggregate bandwidth requirement.

So, while both MQTT and DDS provide standard communication foundations for the Internet of Things, their architectures lend themselves to very different deployment topologies. Choosing a centralized solution when your data flows are distributed could have a profound impact on your applications’ scalability and efficiency.

Let Us Know What You Thought of the Article.

Leave a Comment Below.

FREE EBOOK

Leading Applications & Architecture for the Industrial Internet of Things

Download Now

Subscribe to Email Updates