Traditional Messaging Solutions Lose to Data Centricity, Discovery, QoS, and More

Different Internets of Things

Applications designed for the Consumer Internet of Things (IoT) and the Industrial IoT must be able to efficiently scale and securely share data. However, there are qualitative differences in system requirements for these two types of IoT applications:

Graph

Qualitative Comparison of system requirements for Consumer and Industrial IoT applications

Source:  Cutter Journal December 2014

The Consumer and Industrial IoT share many of the same requirements. However, each requirement has a very different relative importance. For example, Industrial IoT applications must deal with high individual data rates. Single sources, such as an aircraft engine, produce high volumes of data. Consumer IoT applications don’t usually deal with high individual data rates. However, all IoT applications must deal with high aggregated volumes of data.

Different Protocols

Several specialized messaging/data-sharing protocols are often considered for IoT applications, including

  • Message Queue Telemetry Transport (MQTT), a broker-reliant publish/subscribe messaging protocol designed to be used with TCP/IP
  • Advanced Message Queuing Protocol (AMQP), which defines an efficient, binary, peer-to-peer protocol for transporting messages between two network processes (usually a client and a broker)
  • Constrained Application Protocol (CoAP) is a software protocol that was designed to support the connectivity of simple low power electronic devices (e.g. wireless sensors) with Internet based systems

The following table provides a comparison of the technologies listed above. A number of these IoT protocols were designed for simplicity and as such can support only a very limited set of use cases.  DDS on the other hand is a feature-rich standard that transparently handles much of an IoT system’s data connectivity complexity, therefore, easing developer efforts.

graph 3

 

DDS: The Right Choice

Many real systems include devices, servers, mobile nodes, and more. They have diverse communication needs, but it’s better – and easier – to use a single communication paradigm when possible. System designers should determine which of the protocols meets the primary challenge of their intended applications. Then, if possible, extend that primary choice to all aspects of the system.

For example, inter-device data use is a different use case from device data collection. Requirements for turning on your light switch (best with CoAP) are much different than the requirements for managing the generation of  that power (best with DDS), monitoring the transmission lines (best with MQTT), or communicating power usage within the data center (best with AMQP).

Overall, DDS is the most versatile of these protocols. It can manage tiny devices, connect large, high-performance sensor networks and close time-critical control loops. It can also serve and receive data from the cloud.

DDS communication is peer-to-peer. Elimination of message brokers and servers simplifies deployment, minimizes latency, maximizes scalability, increases reliability, and reduces cost and complexity. Using DDS does require building a data model and understanding data-centric principles. It is ideal for IoT applications that require a lasting, reliable, high-performance architecture.

Skip to toolbar