IIoT Solutions | 6 Industrial IoT Communication Solutions

**Please note that with the April 2024 release of Connext Professional 7.3 LTS, the functionalities formerly comprising Connext Secure are now available as an optional component to Connext Professional, named Security Extensions. 

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.

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.

1. 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.

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.