Industrial Internet Connectivity Document Evaluates Core Standards: DDS, OPC-UA, WebServices 2

The Industrial Internet Consortium has released an important part of its Reference Architecture guidance: its Connectivity Framework document. This is actually pretty important; this document dives into the detail on connectivity for IIoT systems, establishes criteria for evaluating connectivity technologies/standards and puts forward some likely technologies for core connectivity standards, including DDS, OPC-UA and WebServices. In other words, there is some really valuable guidance here.

What is Connectivity for IIoT Systems?

According to the Industrial Internet of Things Connectivity document, “connectivity provides the ability to exchange information amongst participants within a functional domain, across functional domains within a system and across systems. The information exchanged may include sensor updates, events, alarms, status changes, commands, and configuration updates.” More concretely, connectivity is the critical, cross-cutting function that supports interoperability within and across IIoT systems. Moving beyond the current mish-mash of proprietary and vertical-industry-specific standards to an open IIoT standards-based framework is the goal of this work.

Looking at Connectivity from a technical viewpoint, figure 1 shows where the Connectivity function lies on a Network, Connectivity, and Information stack, and it divides Connectivity into 2 different layers: Transport and Framework. The Transport layer provides technical interoperability, with “Bits and Bytes shared between endpoints, using an unambiguously defined communication protocol.” The Framework layer provides syntactic interoperability, with “Structured data types shared between endpoints. Introduces a common structure to share data; i.e., a common data structure is shared. On this level, a common protocol is used to exchange data; the structure of the data exchanged is unambiguously defined.” Addressing connectivity needs up through the syntactic interoperability provided by the connectivity framework layer and assessing connectivity framework standards is one of the important contributions of this document.


Figure 1. Connectivity, using the Networking functions below – Internet Protocol, provides the layers for communicating messages and data between system participants.

The Concept of a Core Connectivity Standard.

To ensure interoperability within and across IIoT systems, the Connectivity Framework document recommends the use of a core connectivity standard. Figure 2 shows how this core standard becomes the connectivity bus for the system, integrating native devices and applications directly and legacy, or non-core-standard devices and applications through protocol gateways or bridges. In this way non-standard entities can be “normalized” into the core connectivity standard. This core connectivity reference architecture is central to the IIC’s guidance on ensuring secure, device to device to application interoperability for IIoT systems.


Figure 2. Using a Core Connectivity Standard provides for interoperability and streamlined integration within and across IIoT systems.

Evaluating Connectivity Standards.

To reduce the integration and interoperability challenge across different IIoT systems, a key goal of the IIC, the document provides a method and template for evaluating connectivity technologies and standards for the IIoT. It includes assessments of most IIoT standards like DDS, OPC-UA, HTTP/WebServices, OneM2M, MQTT and CoAP. Many of these standards turn out to address different levels of the connectivity stack as you can see in figure 3. Further details on each standard are provided in the document.


Figure 3. IIoT connectivity standards and their location on the connectivity stack.

DDS as a Core Connectivity Standard.

From figure 3, you can see that the document assesses 4 connectivity framework standards including DDS. In addition, the Connectivity Framework document provides guidance on requirements for choosing core connectivity framework standards. A core connectivity framework must:

  • Provide syntactic interoperability
    • Provide way to model data, a type-system (e.g. DDS, OPCUA)
    • Can’t be just a “simple” messaging protocol (MQTT, COAP, etc)
  • Be an open Standard with strong governance:
    • from SDOs like IEEE, OASIS, OMG, W3C, IETF
  • Be horizontal & neutral
  • Be stable and deployed in many industries
  • Have standards-defined core gateways to all other connectivity core standards
  • Provide core functions like publish-subscribe, request-reply, discovert, etc.
  • Meet non-functional requirements: performance, scalability, security, …
  • Meet business criteria: not require single components from single vendors, have supported SDKs, have open source implementations, etc.

In figure 4, you can see the 4 potential core connectivity framework standards assessed against these requirements. DDS supports all the requirements and is a promising standard for IIoT systems across all industries.


Figure 4. IIoT Connectivity Core Standards Criteria applied to key connectivity framework standards.

In particular, if you compare DDS with another promising connectivity framework standard, OPC-UA, from figure 5 below, you can see that they address very different system use cases. If your primary challenge is integrating software applications across an IIoT system, then DDS is a good choice. If you challenge is to provide an interface for your edge device to allow system integrators to later integrate it something like a manufacturing workcell, then OPC-UA is a good choice.


Figure 5. Non-overlapping system aspects addressed by the core connectivity framework standards.

As you can see, this IIC document provides a lot of important guidance and clarifying concepts for IIoT connectivity. You can use it’s IIoT connectivity standards assessment profile to assess other standards you may be interested in for your system, or use its guidance to choose among the leading standards. For more detail download the document for yourself.

2nd Version of the Industrial Internet Reference Architecture is Out with Layered Databus Reply


A year and a half ago the IIC released the first version of the Industrial Internet Reference Architecture (IIRA) – now the second version (v1.8) is out. It includes tweaks, updates and improvements, the most important or interesting of which is a new Layered Databus Architecture Pattern. RTI contributed this new architecture pattern in the Implementation Viewpoint of the IIRA because we’ve seen it deployed by hundreds of organizations that use DDS. Now it’s one of the 3 common implementation patterns called out by the new version of the IIRA.

So, what is a databus? According to the IIC’s Vocabulary document, “a databus is a data-centric information-sharing technology that implements a virtual, global data space, where applications read and update data via a publish-subscribe communications mechanism. Note to entry: key characteristics of a databus are (a) the applications directly interface with the operational data, (b) the databus implementation interprets and selectively filters the data, and (c) the databus implementation imposes rules and manages Quality of Service (QoS) parameters, such as rate, reliability and security of data flow.”

For those who know the DDS standard, this should sound familiar. You can implement a databus with a lower level protocol like MQTT, but DDS provides all the higher-level QoS, data handling, and security mechanisms you will need for a full featured databus.

As we look across the hundreds of IIoT systems DDS users have developed, what emerges is a common architecture pattern with multiple databuses layered by communication QoS and data model needs. As we see in the figure below, we’ll usually see databuses implemented at the edge in the smart machines or lowest level subsystems like a turbine, a car, an oil rig or a hospital room. Then above those, we’ll see one or more databuses that integrate these smart machines or subsystems, facilitating data communications between them and with the higher level control center or backend systems. The backend or control center layer might be the highest layer databus we see in the system, but there can be more than these three layers. It’s in the control center (which could be the cloud) layer that we see the data historians, user interfaces, high-level analytics and other top-level applications. From this layer, it’s straightforward to zero in on a particular data publication at any layer of the system as needed. It’s from this highest layer that we usually see integration with business and IT systems.


The Layered Databus Architecture Pattern: one of three implementation patterns in the newly released Industrial Internet Reference Architecture v1.8.

Why use a layered databus architecture? As the new IIRA says, you get these benefits:

  • Fast device-to-device integration – with delivery times in milliseconds or microseconds
  • Automatic data and application discovery – within and between databuses
  • Scalable integration – comprising hundreds of thousands of machines, sensors and actuators
  • Natural redundancy – allowing extreme availability and resilience
  • Hierarchical subsystem isolation – enabling development of complex system designs

If you want to dig into the databus concept, especially as it compares with a database (similar data-centric patterns for integrating distributed systems, but different in the way they integrate via data), take a look at this earlier blog post on databus versus database.

In addition to the new IIRA release, the IIC is getting ready to release an important document on the Connectivity Framework for its reference architecture. Look for much more detail on this document that sets out core connectivity standards for the Industrial Internet.

The First Smart Healthcare Testbed at the Industrial Internet Consortium Reply


Today, Infosys, RTI, PTC, and Massachusetts General Hospital’s MD PnP Lab launched the Industrial Internet Consortium’s (IIC) entry into smart healthcare.

Healthcare is an industry in transition. The current, poorly connected state of healthcare systems limits progress in this field and is an obstacle in the goal of providing better medical treatment at lower costs. The need for better systems is urgent. Today, hospital errors contribute to hundreds of thousands of deaths in the US every year. And with at least 80% of older adults suffering from one or more chronic health issues, there is an enormous opportunity to improve healthcare and prevent unnecessary loss of life.

The rise of the Industrial Internet of Things (IIoT) promises a better future. With the IIoT, we can create intelligent distributed systems of devices that check patient status, better inform doctors of status, and prevent errors. New healthcare systems can provide remote monitoring and care both in the home and small clinics. This revolution will lower cost, improve patient outcomes, enable much better care in hospitals and homes, and improve long-term care.

The new Connected Care Testbed applies the IIC’s leading reference architecture to demonstrate and prove connected care systems for hospitals, homes, and clinics. The goal is to develop an open IIoT architecture for clinical and remote medical devices. It will integrate patient monitoring data with data management and analytics. The testbed leverages the OpenICE medical device framework to ensure secure interoperability between medical devices and applications. RTI Connext DDS, already used by the MD PnP Lab, will be the data distribution middleware for the testbed.

Testbed use case: A doctor receives a text message warning about one of her patients, and logs into her user account on the Connected Care system. On the summary dashboard, the system has highlighted one of her patients that may need follow up. Clicking on the patient’s name, the doctor accesses the patient’s health history and sees a highlighted alert that the patient has been taking medication incorrectly (as recorded by a sensor in the patient’s home ). The doctor then views details of the patient’s medication use and is able to determine the problem. With another click, the doctor is able to forward the alert to her staff for follow up with a note to discuss proper use of medication with the patient.

As the lead on the testbed, Infosys will be doing much of the system development and integration. Infosys has identified a family willing to participate in the first phase for home monitoring. The plan is to use home monitoring devices like a FitBit Activity Monitor, a smart scale, a Withings blood pressure monitor, a GreatCall fall detection system, and an Ivy Vital-Guard 450C patient monitor. The goal is then to find a hospital or clinic partner and use the MD PnP Lab at Massachusetts General Hospital for initial data collection for clinical monitoring. Data gathering at the MD PnP Lab already uses RTI Connext DDS in its implementation of the OpenICE framework, while RTI and the MD PnP Lab continue to develop the OpenICE framework.

As a coordinating activity, RTI collaborates with the MD PnP lab on securing data in an OpenICE system. Security is critical for many reasons. First, laws such as the Health Insurance Portability and Accountability Act (HIPAA) mandate patient privacy. Also, security attacks can have serious safety consequences for patients. In a phase 1 SBIR project for the Defense Health Program, RTI modeled security requirements for a set of key care environments and worked out security risks for ICE deployments in each setting. RTI then demonstrated how and to what extent the risks would be mitigated by using an ICE Controller that complies with the recently adopted DDS security specification. Collaborating with the MD PnP lab, we developed a proof-of-concept prototype. We recently used this proof-of-concept as an example in our tech lab at the RSA Conference, and we plan to use the lessons learned in this research in the Connected Care testbed too.

Learn more on the IIC site, or watch this video to hear what the Infosys, MD PnP, and RTI have to say about the Connected Care Testbed.