A Day in Your Life with the Internet of Things Reply


Good morning, Irving. It’s 6:40am on October 8, 2023. Let’s follow you today, a day in the Internet of Things.

First, you wake up a bit early because your clock realized there’s more traffic than usual on the way to work. Your coffee is ready, your house is warmed up, and your dog is waiting for his walk.

However, your bedside health status monitor tells you that your heart was erratic last night. It’s been communicating with your cloud-based health analytic service, and the algorithm asks you how you feel. Unfortunately, your chest feels heavy. The monitor notes a disturbing anomaly and recommends you call 911. (We didn’t say this was going to be a good day in the Internet of Things.)


Community: A Major RTI Initiative Reply


RTI launched a major community initiative this year.  Our goal?  To enable dynamic and powerful community collaboration.  Founded on the best ecosystem in the real-time middleware industry, the RTI Community will ease communication and sharing between our customers, employees, and partners.

Many resources are already live on community.rti.com!  The forum is energized, with many of our engineers in active conversations, offering solutions and advice to customer queries. And you won’t want to miss the new offerings:

  • New and expanded knowledge base
  • Best-practices guide
  • Glossary of domain terms
  • Examples library
  • File exchange
  • Searchable documents and media


Internet of Things: Collect Device Data with MQTT & Use Device Data with DDS Reply

As David Barnett points out in his recent blog, the Internet of Things needs many protocols.  Two of them, MQTT and DDS, are rapidly becoming the best ways to connect large numbers of devices.  The confusion is understandable; the high-level positioning is similar.  Both can connect thousands of devices into real-time machine to machine (M2M) networks.

However, they target very different needs.

MQTT targets device data collection.  Its name, the Message Queue Telemetry Transport, points this out; the main purpose is telemetry or remote monitoring (see http://en.wikipedia.org/wiki/Telemetry).  The goal of MQTT is to collect data from many devices and transport that data to the IT infrastructure.   It targets large networks of small devices that need to be monitored or controlled from the cloud.  There is little attempt to enable device-to-device transfer, nor to fan out the data to many recipients.  Since it has a clear, compelling single application, MQTT is simple, offering few control options.  It also doesn’t need to be particularly fast; in this context, real-time is typically measured in seconds.

A hub-and-spoke architecture is natural for MQTT.  All the devices connect to a data concentrator server, such as the new IBM MessageSight appliance.  You don’t want to lose data, so the protocol works on top of TCP, which provides a simple, reliable stream.  Since the data is used by the IT infrastructure, the entire system is designed to easily transport data into enterprise technologies like ActiveMQ and ESBs.

DDS, on the other hand, targets device data use.  Its name, the Data Distribution Service, also points out its goal: to distribute data to other devices.  While interfacing with the IT infrastructure is supported, DDS exists to connect devices to other devices.

Devices demand data very differently than the IT infrastructure demands data.  First, devices are fast; real-time is often measured in microseconds.   Devices need to communicate with many other devices in complex ways, so the simple reliable point-to-point streams of TCP are far too restrictive.  Instead, DDS offers detailed quality of service control, multicast, configurable reliability, and pervasive redundancy.  Fan out is a key factor; DDS offers powerful ways to filter and select exactly which data goes where — which can be thousands of simultaneous destinations.  Some devices are small, so there are lightweight versions of DDS that run in constrained environments.  But there are also powerful full-featured versions that support large participants in the device network.

Hub-and-spoke is completely inappropriate for device data use.  Rather, DDS implements direct device-to-device bus communication with a relational data model.  RTI calls this a databus, because it is the networking analog to a database.  Similar to the way a database controls access to stored data, a databus controls data access and updates by many simultaneous users.  This is just what many high-performance devices need to work together as a single system.

Bottom line: Device data use is a fundamentally different use case from device data collection.  Data distribution (DDS) enables devices to use other devices’ data to work together as a coherent system.  Data telemetry (MQTT) enables IT infrastructure to monitor and collect data from many devices, thus connecting them to the cloud.  There is some overlap: DDS can serve and receive data from the cloud, and MQTT can send information back out to devices.  But the fundamental goals differ, the architectures differ, and the capabilities differ.  Both protocols are critical to the (rapid) evolution of the Internet of Things.