6 Industrial IoT Communication Solutions – Which One’s for You? [Comparison] 4

Which Industrial IoT messaging solution is the right one for you?

To say that the task of selecting your Industrial IoT (IIoT) communication infrastructure is a very complex undertaking would be an understatement. The evaluation of the myriad of commercially available solutions is both time consuming and expensive. Try downloading and evaluating multiple solutions of each type of infrastructure and you will quickly find yourself in the midst of a project that will take several engineers a good six months to complete. We’ve all been there, and I want to help you save yourself some valuable time!

The purpose of this post is to introduce you to the popular IIoT infrastructure solutions that are commercially available – AMQP, CoAP, DDS, RTI Connext DDS, MQTT, and ZeroMQ – and to highlight the capabilities of each solution. The six following areas of evaluation will be applied: Architecture, Communication Patterns, Transports, Data Type & Filtering, Quality of Service and Security.

Click the here to download the printable version.

Click the here to download the printable PDF version.

1. Architecture

Depending on the architectural pattern of a given communications infrastructure, the logical connection (illustrated in Figure 1, below) applications will use to communicate with other applications across the infrastructure varies. The two most basic architectures used in today’s middleware solutions are (1) peer-to-peer and (2) broker based star architectures.

Peer-to-peer architectures enable applications to communicate directly with each other without having to send data to an intermediary element. These architectures are inherently more efficient at data delivery since only the sending and receiving applications are expending CPU resources to complete the transfer. Therefore only the applications that have the data and the applications that need the data will consume CPU cycles; thus results in an efficient distribution of processing based on application requirements. The other benefit for a peer-to-peer architecture is that deterministic delivery of data is much more achievable because there is no “Middle Man” handling the data between the producer and consumer applications.

The Evolution of Communications - IoT Protocols

Figure 1. Architectural diagrams for the various IoT protocols.

Broker based solutions require all applications that are sending data to transfer the data directly to the broker server, after which it will turn around and resend this data to the receiving applications. The benefit of this architecture is that the broker manages all of the complexity relating to sending/receiving data. Typically these solutions have built-in tools for seeing exactly which data paths are active, who is sending data, and who is receiving data. Broker based solutions do introduce latency to data delivery and also present a single point of failure such that if the broker fails, all communications fail as well. To solve the single point of failure problem, most of these implementations provide for redundant and highly available broker servers.

2. Communication Patterns

Communication pattern support is essential to an infrastructure that you can use throughout the lifecycle of your project or product line. The initial project may only require publish/subscribe, but subsequent projects or products may need additional patterns like request/reply or queueing. In this aspect, not all existing IoT solution available today can support all the necessary patterns your project will need. For the comparison table, we have identified the most common patterns used today and whether each infrastructure solution provides that pattern. These are the most common patterns in use today:

  • Publish / Subscribe: An application (subscriber) requests data 1 time and then all subsequent updates to the data are then “Pushed” to the subscriber. No need to ask for data updates continually.
  • Request/Reply/RPC (Remote Procedure Call): A requester application sends requests, and a replier application replies to the request.
  • Queueing (or Point-to-Point): Data is pushed to a server that will hold the information in a Queue. Data can then be either pulled from the queue or pushed to consumers. Unlike in Publish/Subscribe, each piece of data is distributed to only one receiving application.
  • One to Many: Ability to have a many receiving applications get the same data from a single source.
  • Many to One: Ability to receive data from many sources into a single consuming application.

3. Transports & Routing/Bridging

Most communication middleware solutions support TCP as their primary communication protocol. Using TCP gives you a reliable delivery of data using the built-in reliability mechanism inherent to TCP. This can be ideal for specific data flows that require reliability but is overkill and adds unnecessary overhead to simple sensor data that does not require reliable delivery. Some of the IoT solutions like ZeroMQ and DDS also support other transports such as shared memory. One transport of note is the use of the UDP transport for DDS. Because the implementation of reliability is built-in to DDS, it does not require a reliable transport underneath. This enables applications to pick and choose which data flows are reliable delivery and which flows that are best effort.

Routing of data between transports and across the WAN is something that all of these solutions provide in some way or other. In today’s world where enterprise systems, leveraging ESB’s and Web technologies, must also access some of the real-time data, it is essential for communication middleware also to support connecting to these technologies. Because of this, you will see routing and bridging as a core component for distributed system middleware.

4. Data Type & Filtering

How data is encapsulated and represented on the wire is also unique to the given infrastructure. Some solutions only send across raw bytes of data, and it is up to the application to serialize and deserialize the data. Others only send text/string data so that either the information can be represented in XML or JSON format. This scenario is very common in web technologies today, but can be very inefficient because with every send of data the packet also contains the description of the data, sometimes making the packet size more than 3x its original size. Larger packet sizes increase bandwidth usage as well as increase CPU usage on both the sending and receiving sides of the transfer. Put a broker in the middle of that and you also now double the number of packets on the wire.
Other solutions, such as DDS, enable the use of strongly typed data that is uniquely serialized and deserialized by the middleware. The schema is sent separately, which is not the case with XML or JSON, and therefore you don’t pay a penalty per message (or sample). This also becomes very important for filtering aspects as well. Let’s say you are setting up a single publisher with many subscribers. Some of the subscribers may want all of the data but some of the subscribers will only want a portion of the data. Without having a strongly typed data solution, your applications will have to manage all of this filtering functionality, which is yet more code you have to write. With solutions like DDS where the type information is strongly defined, the middleware can manage all of the filtering for you. Less code = happier developers :). In fact, RTI Connext DDS has additional functionality for providing this filtering on the writer side of the data transfer, thus resulting in less bandwidth usage on the wire and less CPU processing on applications that do not need the data being filtered out.

5. Quality of Service

Not all data is created equal. What does this mean? Well, some data in a real-time distributed application is streaming sensor data. Most of the time this kind of data does not need to be guaranteed delivered data. For a given sensor, you may just care that a given deadline for delivery of data has been met or more importantly, not met. Other data might be Alarm / Event data. This data does not have a periodicity to its frequency of availability. However, guaranteeing its delivery is very important. Also important to Alarm / Event data is the knowledge of whether that data source is alive or not. If an alarm producer is not alive, this could cause catastrophic events within your real-time system. These are just a few of the Quality of Service (QoS) aspects that govern the various data flows of your application. Quality of Service is one area where DDS is unique as compared to all the other IIoT solutions out there today. DDS, the standard, was built from day one to address the notion that QoS is applicable on a per Topic basis.

Here are all of the QoS (DDS and MQTT) that can be defined on either a producer basis, consumer basis, or both:

DDS QoS Policies

  • Reliability / Best Effort
  • History
  • Deadline
  • Liveliness
  • Lifespan
  • Time-Based Filter
  • Durability
  • Reader / Writer Lifecycle
  • Latency Budget
  • Transport Priority
  • Ownership
  • Resource Limits
  • Partition
  • Destination Order
  • User Data, Group Data, Topic Data

For a description of these QoS available from DDS, please see this resource. While DDS is unique in the QoS policies that it does provide, the other infrastructure solutions also provide some limited QoS capabilities. These QoS capabilities are structured around making the broker the basis for solutions to support redundancy and high availability. When using MQTT, there are 3 basic QoS settings:

MQTT QoS Policies

  • QoS 0: At most once delivery
  • QoS 1: At least once delivery
  • QoS 2: Exactly once delivery

For a description of MQTT QoS, please see this resource.

6. Security

Do you worry about the data in your system being compromised? If not, you either need to have a very tight physical security solution in place or your data is just not that critical if it were to be accessed and/or manipulated by outside threats. To combat this, most of the IoT communication solutions employ an SSL/TLS transport for protecting their data transfers between producers and consumers. ZeroMQ also provides an authentication solution using SASL. DDS is the only solution that enables Authentication, Access Control, Encryption/Decryption, Data Tagging and Logging to be specified on a per data flow (Topic) basis. This security implementation, as defined by the OMG DDS Security specification basically connects together the concepts of Authentication and Access Control with Discovery. For more information related to DDS Secure, please see this resource.

Now that you have all of the information you can narrow down your evaluation phase to just a couple of solutions that are relevant to the type of application you are trying to deliver. Good luck!

Click here to download the printable PDF version.

7 Things You Can Do With RTI Shapes Demo Reply


Think it’s time to dust off your Connext DDS skills? Do you want to impress your boss and co-workers with all of the cool things Connext DDS can do for your projects, quickly? We know that showing the power of infrastructure tools can be challenging, but we have a solution: RTI Shapes Demo. Matrix, an RTI partner, has created some amazing videos that we’ve compiled into one, which is sure to get your creativity flowing!

The video features the following seven scenarios. All of them were created through variations in DDS configurations using the Shapes demo.

  1. Introduction to IDL: see how to use Interactive Data Language to generate DDS topics.
  2. Basics of QoS: quickly learn QoS fundamentals, such as History, Content Filter topic and Time Based filter.
  3. Excel Spreadsheets Demo: teach Excel new tricks and watch your real-time data coming to life in dynamic diagrams and charts!
  4. History QoS: research the benefits of History QoS for your project.
  5. Late Joiner Read: learn about Durability and History QoS by comparing the behavior of a late joiner and an alive subscriber.
  6. Partition QoS: understand a concept of “visibility planes” associated with Partition QoS.
  7. DDS Versioning Capability (X-Types): learn how to use the power of DDS X-Types for evolving your systems while maintaining backward compatibility.


Are you ready to advance your knowledge and try out these scenarios for yourself? Simply download and install the Shapes Demo application now! It’s a free RTI Connext DDS learning tool that everyone on your team can learn quickly, and it requires no coding.

Robots on Wheels – By 2021, This May Be the New Normal Reply

autonomous cars robots on wheels ride sharing 2021

If you drive a car, I suggest you read this post by Mark Fields, CEO of Ford Motor Company. Ford is staking their claim in the driverless car market, and it is a bold one. Ford expects to mass-produce driverless cars in 2021 for ride-hailing and ride-sharing services. And this isn’t an advanced autopilot or car with self-driving capabilities; this is a “No steering wheel. No gas pedals. No brake pedals. A driver will not be required.” fully driverless car.

Ford has decided that Level 3 automation, defined by the US Department of Transportation as semi-autonomous driving where the driver needs to take over with ‘reasonable notice,’ is not worth pursuing and instead they are going directly for Level 4, a fully driverless car. Ford isn’t the only company investing and preparing for this future, but they have made a very public and bold statement that should accelerate investment in this market. It should also signal to any car company that doesn’t already have an advanced program to develop self-driving cars: you may already be too late.

It is also interesting that Ford will provide self-driving cars for ride-sharing services first. This is a smart move because it will allow them to retain control of the vehicles (with ride-sharing partners) and they will be able to collect the massive amount of data needed to improve the safety and operation of these systems.

This will be a great social experiment. How will society adapt to having cars available on-demand that will take us anywhere? How fast can we reduce the number of motor vehicle deaths (30,000/yr in the United States) by a factor of 10x? The future is almost here, and it isn’t hover-boards or self-drying clothes but is ubiquitous transportation for everyone, available instantly at the touch of an app.

Click here to learn more about RTI and Autonomous Cars.