1660251653680 Stanschneiderbw346px2

Data Connectivity in the Industrial Internet Reference Architecture

Sept. 2, 2015

The IIRA is a formal overview of systems architecture from a high-level perspective. It covers everything from business goals to system interoperability. For now, let’s concentrate on how this applies to data connectivity.

Recently, the Industrial Internet Consortium (IIC) published the first version of the Industrial Internet Reference Architecture (IIRA). The first public release is a formal overview of systems architecture from a high-level perspective.  It covers everything from business goals to system interoperability.

The goal of the IIRA is ambitious; it must span the Industrial Internet of Things (IIoT) across many industries, including manufacturing, medical, transportation, energy, and industrial control. These systems traditionally use industry-specific standards and architectures.  Combining these by brute force won’t work; they are too different.  To span the IIoT, the IIRA must somehow rise above that confusion to achieve practical generality.

Of course, this challenge has many dimensions.  In this blog, I will address just one: “connectivity.”  Connectivity determines the fundamental patterns, data types, and protocols of how “things” communicate.  The IIRA takes an innovative, distributed “Core Connectivity” approach that eases interoperability while providing practical performance, reliability, and security.

The Power of Common Architecture

First, we must ask a key question: why even have a common architecture?  The answer is simple: ultimately, the IIoT is about building distributed systems. Connecting all the parts intelligently so the system can perform, scale, evolve, and function together with a common interconnection is the crux of an “Internet”.  Also, without common architecture, industries cannot leverage the lessons learned in other venues.  Analytics applications, for instance, are generically useful for many industries.  Common architecture leverages that generality to drive down costs for all.  Finally, over time, non-intuitive relationships enable entire new industries.  At the dawn of the “enterprise” Internet, the mixing of an address book with retail was non-obvious.  Today, of course, it is an important driver of the social media industry.

Stan will be providing a complete look at the Industrial Internet Reference Architecture during his keynote at Smart Industry 2015.

Thus, to enable the IIoT, we need to develop a common architecture that can span sensor to cloud, interoperate across vendors, and bridge industries.  Over time, common technologies that span industries always replace bespoke systems.  However, incremental adoption and adapting current technology are also crucial. The IIRA must therefore integrate many standards and connectivity technologies. The IIC architecture explicitly blends the various connectivity technologies into an interconnected future that can enable the sweeping vision of a hugely connected new world.

The Integration Challenge

When you connect many different systems, the fundamental problem is the “N squared” interconnect issue. Connecting two systems requires matching many aspects, including protocol, data model, and communication pattern.  It also requires, explicitly or not, matching quality of service (QoS) issues like reliability, data rate, and timing deadlines. While connecting two systems is a challenge, it is solvable with a special-purpose “bridge”. But, the special-bridge approach doesn’t scale; connecting N systems together requires N-squared bridges. As N gets large, this becomes daunting.

One way to ease this problem is to keep N small. You can do that by dictating all standards and technologies across all systems that interoperate. Many industry-specific standards bodies successfully take this path. For instance, the European Generic Vehicle Architecture (GVA) specifies every aspect of how to build military ground vehicles, from low-level connectors to top-level data models. The Industrie 4.0 effort takes a similar pass at the manufacturing industry, making choices for ordering and delivery, factory design, technology, and product planning. Only one standard per task is allowed.

This approach eases interoperation. Unfortunately, the result is limited in scope because the rigidly chosen standards cannot provide all functions and features. There are simply too many special requirements to effectively cross industries this way.  Dictating standards also doesn't address the legacy integration problem. These two restrictions (scope and legacy limits) make this approach unsuited to building a wide-ranging, cross-industry Industrial Internet.

On the other end of the spectrum, you can build a very general bridge point. Enterprise web services work this way, using an “Enterprise Service Bus” (ESB) like Apache Camel.  However, despite the “bus” in its name, an ESB is not a distributed concept. All systems must connect to a single point, where each incoming standard is mapped to a common object format. Because everything maps to one format, the ESB requires only “one-way” translation, avoiding the N-squared problem.  Camel, for instance, supports hundreds of adapters that each convert one protocol or data source.

Unfortunately, this doesn’t work well for demanding industrial systems.  The single ESB service is an obvious choke and failure point. ESBs are large, slow programs. In the enterprise, ESBs connect large-grained systems executing only a few transactions per second. Industrial applications need much faster, reliable, smaller-grained service.  So, ESBs are not viable for most IIoT uses.

The IIRA Connectivity Core Standard

The IIRA connectivity architecture specifies a quality-of-service controlled, secure “core connectivity standard”. All other connectivity standards must only bridge to this one core standard.

The IIRA takes an intermediate approach. The design introduces the concept of a "Connectivity Core Standard". Unlike an ESB, the core standard is very much a distributed concept. Some endpoints can connect directly to the core standard. Other endpoints and subsystems connect through “gateways”. The core standard then connects them all together. This allows multiple protocols without having to bridge between all possible pairs. Each needs only one bridge to the core.

Like an ESB, this solves the N-squared problem.  But, unlike an ESB, it provides a fast, distributed core, replacing the centralized service model. Legacy and less-capable connectivity technologies transform through a gateway to the core standard. There are only N transformations, where N is the number of connectivity standards. 

Obviously, this design requires a very functional core connectivity standard. Some systems may get by with slow or simple cores. But, many industrial systems need to identify, describe, find, and communicate a lot of data with demands unseen in other contexts. Many applications need delivery in microseconds or the ability to scale to thousands or even millions of data values and nodes.  The consequences of a reliability failure can be severe.  Since the core standard really is the core of the system, it has to handle the system’s most challenging aspects.

The IIRA specifies the key functions that connectivity framework and its core standard should provide: data discovery, exchange patterns, and “quality of service” (QoS). QoS parameters include delivery reliability, ordering, durability, lifespan, and fault tolerance functions.  With these capabilities, the connectivity framework can support the reliable, high-speed, secure transport required by demanding applications ranging across industries.

Security is critical. To make security work correctly, it must be intimately married to the architecture. For instance, the core standard may support various patterns and delivery capabilities. The security design must match those exactly. For example, if the connectivity supports publish/subscribe, so must security. If the core supports multicast, so must security. If the core supports dynamic plug-n-play discovery, so must security. Security that is this intimately married to the architecture can be imposed at any time without changing the code. Security becomes just another controlled quality of service, albeit more complexly configured.  This is a very powerful concept.

The IIC is also working on characterizing systems.  Unlike previous efforts, the IIRA strives to classify applications by their architectural needs, rather than their industrial environments.  Different types of applications require very different architectures and standards.  The first release of the IIRA does not recommend standards.  The IIC will take that step in the next release; the long-term goal is to develop guidance, allowing designers to make industry-independent choices.  For connectivity, this guidance must span the range of connectivity solutions from very high-performance machine-connectivity standards like DDS (Data Distribution Service) to relatively slow generic enterprise technologies like HTTP.   

Doing this across industries is a huge challenge.  The IIC is uniquely positioned to make this contribution.  With over 200 companies, the IIC has an immense experience pool.  The IIC ecosystem includes companies in the power, medical, transportation, manufacturing, and control industries.  It also includes technology vendors in chips, networking, software, messaging, analytics, and telecommunications.  The combined lessons learned across thousands of applications, as contributed by the top architects from 200 companies, promise to drive the design of the IIRA and transform the industrial landscape.

Stan Schneider is CEO at Real-Time Innovations (RTI), the Industrial Internet of Things communications platform company. RTI is the largest embedded middleware vendor and has an extensive footprint in all areas of the Industrial Internet, including energy, medical, automotive, transportation, defense, and industrial control.

In 2014, Stan was elected to the Industrial Internet Consortium Steering Committee. With over 140 companies, the goal of the IIC is to develop, test, and promote the standards that are crucial to the success of the next industrial revolution. Before RTI, Stan managed a large Stanford robotics laboratory, led an embedded communications software team and built data acquisition systems for automotive impact testing. He is also an active member of the Smart Industry Advisory Board.

Stan will be providing a complete look at the Industrial Internet Reference Architecture during his keynote at Smart Industry 2015.