Success-Plan Services
Stan Schneider
Today, the Industrial Internet Consortium (IIC) released the Industrial Internet Reference Architecture (IIRA). The IIC is the largest of the Internet of Things (IoT) consortia with over 170 members (iiconsortium.org). More importantly, it’s the only one focused on industrial systems. The first public release of the IIRA is a formal overview of the systems architecture from a high-level perspective. It covers everything from business goals to system interoperability. The architecture establishes many key technical guidelines. Critically, it also eliminates many approaches; an architecture is as much about what you can't do as what you can do.
We at Real-Time Innovations (RTI) are most excited by one key aspect: the IIRA connectivity architecture. “Connectivity”, or how things communicate, is one of the biggest challenges for the emerging Industrial Internet of Things (IIoT). The IIRA takes an innovative, distributed “databus” approach that eases interoperability while providing top performance, reliability, and security.
The Power of Common Architecture
Ultimately, the IIoT is about building distributed systems. Connecting all the parts intelligently so the system can perform, scale, evolve, and function optimally is the crux of the IIRA.
To enable the IIoT, we need to develop a common architecture that can span computing capability, 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 IIoT 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.
This is the “interoperability” problem, and it’s really RTI’s specialty. RTI participates in 15 different standards and consortia efforts. They span many industries: naval systems, avionics, power, medical devices, unmanned vehicles, consumer electronics, industrial control, and broadcast television, to name just a few. All focus on how to get systems to work together. The IIC draws on experience from these industries and more.
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, communication pattern, and quality of service (QoS) parameters like reliability, data rate, or timing deadlines. While connecting two systems is a challenge, it is solvable with a special-purpose “bridge”. But it 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 German 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 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, most 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 perform.
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 core connectivity can implement the reliable, high-speed, secure transport required by demanding applications across industries.
Security is also 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 integrated security must extend beyond the core. The IIRA allows for that too; all other connectivity technologies can be secured at the gateways.
DDS as a Core Standard
The IIRA does not specify standards; the IIC will take that step in the next release. However, it’s clear that the DDS (Data Distribution Service) standard is a great fit to the IIRA. DDS provides automated discovery, each of the patterns specified in the IIRA, all the QoS settings, and intimately integrated security.
This is no accident. The IIRA connectivity design draws heavily on industry experience with DDS. DDS has thousands of successful applications in power systems (huge hydropower dams, wind farms, microgrids), medicine (imaging, patient monitoring, emergency medical systems), transportation (air traffic control, vehicle control, automotive testing), industrial control (SCADA, mining systems, PLC communications), and defense (ships, avionics, autonomous vehicles). The lessons learned in these applications were instrumental in the design of the IIRA.
Thank you!
Finally, I would like to close by thanking the teams that built the IIRA. This was a large effort supported by many companies. RTI was most involved with the architecture, connectivity, and distributed data & interoperability teams. Thank you all, and congratulations on your first release.