Juggling Data Connectivity Protocols for Industrial IoT

Real-time needs are key in multiprotocol industrial IoT

With much legacy equipment existing with older protocols and requiring diverse real-time needs, the Industrial IoT will not soon, if ever, use a single data-connectivity standard.

The projected benefits that can be gained from the Industrial Internet of Things (IIoT) have been well documented during the past several years by the likes of General Electric, Accenture and other organizations that have conducted extensive research in this area. In fact, these benefits in revenue, cost reductions and energy consumption are now coming to fruition in a variety of smart city, smart farming, transportation and other industry sectors.

A great example is the Connected Boulevard program in Nice, France, which uses Industrial Internet technologies, including an innovative data-sharing platform, to help manage and optimize all aspects of city management, including parking and traffic, street lighting, waste disposal and environmental quality.

For now, the Industrial Internet of Things will be an environment in which many protocols will coexist.

The key to these benefits is the ability to derive value from the data. The data must be accessible wherever it resides and delivered to wherever it’s needed (edge to the cloud) so that it can be analyzed and acted upon in the right amount of time. There are a range protocols currently used to provide this “data-sharing function” within an Industrial Internet system (see chart above). Chief among them are:

• The Object Management Group’s (OMG) Data Distribution Service for Real-Time Systems (DDS);
• OASIS’ Advanced Message Queuing Protocol (AMQP);
• MQ Telemetry Transport (MQTT), a protocol originally developed by IBM but now an OASIS standard;
• Representational State Transfer (REST), a common style of using HTTP for Web-based applications and not a standard; and,
• Constrained Application Protocol (CoAP), a software protocol to be used in very simple electronics devices such as Wireless Sensor Networks (WSN) that allows them to communicate over the Internet; and,
• The eXtensible Messaging and Presence Protocol (XMPP), the IETF’s formalization of the base XML streaming protocols for instant messaging and presence technology originally developed within the Jabber open-source community.

Comparing Industrial IoT alternatives
DDS is the OMG standard for high-performance and secure data-centric publish/subscribe. DDS is based on a completely decentralized architecture and has built-in dynamic discovery service that automatically establishes communication between matching peers. DDS has a rich set of Quality of Services (QoS) that provides control over every aspect of data distribution, such as data availability, resource usage, e.g. network, memory, etc., and traffic prioritization.

AMQP was designed to address applications requiring fast and reliable business transactions. AMQP, now managed by OASIS, is a standard that defines a binary, peer-to-peer protocol for transporting messages between two processes over a network.

MQTT provides a simple and lightweight device data collection solution, although only partial interoperability between MQTT publishers and subscribers can be guaranteed. Messages can be exchanged between different MQTT implementations but unless the format of the message body is agreed between peers, the message body cannot be un-marshaled.

REST provides a simple client-server (request-reply) style of communications that is useful for systems that need to communicate over the Internet. The stateless model supported by HTTP can simplify server design.

CoAP was designed to support the connectivity of simple low power electronic devices such as sensors, switches, valves and other resource constrained Internet devices such as Wireless Sensor Networks (WSNs). It is often used with WSNs implementing the IETF’s IPv6 over Low Power Wireless Personal Areas Networks (6LoWPAN) standard.

XMPP is a simple communications protocol for message-oriented middleware based on XML (Extensible Markup Language). Designed to be extensible, the protocol has also been used to implement instant messaging, lightweight middleware, voice and video calls, file transfer, gaming, social networking services and IIoT applications.

Selecting among the various IIoT protocols requires determining what kind of connectivity is needed: device to device, device to cloud or cloud to cloud and what needs to be done.
(Source: Prismtech)

Making the right Industrial IoT choice
So how do you choose which protocol is right for your Industrial Internet system? Well, each protocol has a specific set of characteristics and strengths and weaknesses that should be considered when deciding which protocol (or even protocols) is most appropriate (see table above). Key decision points to be considered include:

• What is the communication interaction pattern or patterns required? For example, request-reply, which makes for tightly coupled interactions and is commonly used on the control plane of a system, or alternatively more loosely coupled publish-and-subscribe style communications that is typically used on the data plane.
• What is the desired level of interoperability between systems? Each protocol supports different levels of interoperability for information exchanges between applications and subsystems. For example, protocols such as MQTT enable basic syntactic (also referred to as Foundational Interoperability) whereby systems can exchange messages but how to interpret the data contained in each message is undefined. More sophisticated protocols such as DDS support full Semantic interoperability. Not only can subsystems exchange information but DDS takes advantage of both structuring of the data exchange and the codification of the data including a vocabulary so that the receiving IT system can interpret the data based on a Data Model describing entities that have meaning within the system.
• What are the quality-of-service requirements of the system? MQTT, AMQP and CoAP provide basic QoS support that can be used by an application to control whether message exchanges between applications are best effort or reliable. Protocols such as and XMPP or REST/HTTP have no explicit QoS control and depend on the underlying transport layer (e.g. TCP/IP) for basic message reliability. DDS on the other hand provides tailored data management that enables applications to tune the communications behavior an IIoT system to meet specific requirements. This includes being able to specify, whether data exchanges are reliable or best effort, how long data is available for future use, the ordering of data presented to a subscriber, resource usage (network, memory, etc.) and data traffic prioritization.
• Are connectivity and data exchanges required between devices, between devices and the cloud, and even across clouds? CoAP enables device to device data exchanges between wireless sensors networks and gateway nodes but requires a HTTP bridge to enable communication with the cloud. MQTT on the other was designed for telemetry applications where physical world messages need to be made available to Enterprise and Web Servers and other consumers such as mobile devices (for M2M applications). XMPP provides a general framework for messaging across a network and be used to implement message exchanges for different device and cloud configurations. DDS was designed as high performance Device2Device protocol but can also be used to share data efficiently up to and between clouds and with other subscribers such as mobile applications.
• What is the required communication performance and scalability of the system? Protocols that support a publish-and-subscribe interaction model such as DDS, MQTT and AMQP tend to scale much better that other protocols based on a request-reply model. This is particularly true for one to many or many to many data exchanges. A data-centric protocol such as DDS does not require the use of brokers and supports direct peer-to-peer communications, enabling extremely low latency communications and when used with a network that supports multicast then massive data rates can be achieved.
• What is the level of security required? All of the protocols considered provide data encryption at the transport level, either based on TLS, DTLS or HTTPS. This is usually identified as orthogonal issue to their core standard. AMQP and XMPP also provide support for pluggable authentication based on the Simple Authentication Security Layer (SASL). In comparison, DDS provides a comprehensive security framework and specifies a complete end-to-end AAA (Authentication, Authorization and Accounting) security architecture for DDS-based IIoT systems.

Buyer beware
Clearly there are options to connect devices and exchange data in an IIoT system. However, their suitability to support the different operational scenarios considered varies. This is especially true when key system requirements such as performance, quality-of-service, interoperability, fault tolerance and security are taken into account.

For Device2Device applications that require high performance, real-time, many-to-many managed connectivity then DDS has distinct advantages over the other messaging technologies. DDS is also emerging as a key enabler for connecting real-time device networks to cloud-based data centers.

The choice of the most appropriate data connectivity solution should be based on an understanding of both the architecture and the message/data sharing requirements for each target system.

Finally, it is also apparent that complex IoT environments will not be based on a single data-connectivity standard. There is a vast amount of legacy equipment already deployed using a wide variety of protocols. So, for the foreseeable future these will remain multi-protocol environments. Techniques and strategies are going to be needed to enable multiple protocols to work together if the benefits of the Internet of Things are going to be realized.

Source: http://www.eetimes.com/author.asp?section_id=36&doc_id=1326169