DE · Topics ·

Building an Industrial Internet of Things Architecture

Building an IIoT system or corporate strategy requires companies to journey into the great unknown.

Fig. 1: The IIRA v. 1.8 framework identifies the fundamental architecture constructs and specifies design issues, stakeholders, viewpoints, models and conditions of applicability. System architects and design engineers work with this information to discover, describe and organize topics of interest about the system they are building. Images courtesy of the Industrial Internet Consortium.


The new connected world of the Industrial Internet of Things (IIoT) promises immense opportunity to those who provide products offering enhanced intelligence and connectivity. But companies preparing to develop products to populate this emerging digital ecosystem also face real risks. Developing an IIoT system or corporate strategy requires companies to venture into unknown territory—where technology and business models often don’t exist.

To help developers and their design engineers navigate this uncharted world, the Industrial Internet Consortium (IIC) offers the Industrial Internet Reference Architecture (IIRA) v. 1.8. “The IIRA is a guide explaining how to approach the design process itself,” says Stan Schneider, CEO of Real-Time Innovations and a member of the IIC’s steering committee. “This framework, overall, ensures a complete yet practical approach to designing a new product or business strategy.”

Fig. 1: The IIRA v. 1.8 framework identifies the fundamental architecture constructs and specifies design issues, stakeholders, viewpoints, models and conditions of applicability. System architects and design engineers work with this information to discover, describe and organize topics of interest about the system they are building. Images courtesy of the Industrial Internet Consortium. Fig. 1: The IIRA v. 1.8 framework identifies the fundamental architecture constructs and specifies design issues, stakeholders, viewpoints, models and conditions of applicability. System architects and design engineers work with this information to discover, describe and organize topics of interest about the system they are building. Images courtesy of the Industrial Internet Consortium.

Moving beyond the theoretical realm, the IIC has grounded its reference architecture in real-world knowledge. To create and fine-tune the framework, the consortium drew on feedback from its test beds and the experiences of hundreds of companies and architects from a broad array of industry verticals. Building on a Knowledge Base

The result of this synthesis of knowledge is not a standard. It’s important to keep in mind that the concepts and practices set forth in IIRA v. 1.8 are representative rather than prescriptive. A solid understanding of IIRA is only the first step in a design process that requires adaptation and customization.

The IIRA contains architectural concepts, vocabulary, structures, patterns and a methodology for addressing design concerns. The document defines a framework by adapting architectural approaches from the ISO/IEC/IEEE 42010-2011 Systems and software engineering—Architecture description standard.

Essentially, the IIRA looks broadly at IIoT use cases and attempts to identify the most important and common architecture concerns. It then provides an architectural template and methodology that engineers can use to examine and resolve design issues. In addition, the template and methodology suggest ways of addressing the top concerns, allowing designers to glean insights by examining architecture patterns. Armed with this knowledge, architects and design engineers need only adapt and customize the general template, methodology and patterns based on their specific system or application requirements.

“The IIRA provides a rather comprehensive deliberation over many aspects of designing an IIoT system,” says Shi-Wan Lin, CEO of Thingswise and co-chair of the Industrial Internet Consortium Technology Working Group. “It helps IIoT system designers to avoid missing important architecture considerations. From our experience of using the IIRA to aid in the design of IIC testbeds, the IIRA does help to identify design gaps of missing important system functions or components.”

Multiple Perspectives

The core of the IIRA’s methodology lies in a set of system conceptualization tools called “viewpoints” that enable architects and engineers to identify and resolve key design issues. These viewpoints provide a kind of checklist that breaks down the system design requirements into four categories, or viewpoints, which include business, usage, functional and implementation elements.

These tools provide a framework in which designers can iteratively think through a comprehensive list of architectural features, looking at the architecture from a variety of perspectives. In the process, these viewpoints offer concepts and models that facilitate the identification and resolution of important issues (Fig. 1).

First among these categories is the business viewpoint. Here, the designer examines the proposed system architecture within the context of specific business concerns. These can range from things like business value and expected return on investment to product liability. To verify that the resulting design provides the desired capabilities and meets the business objectives, the designer ascribes benchmarks to measure the success of the system.

The second category is the usage viewpoint, where the engineer looks at the design to determine how the system delivers the key functionality identified in the business viewpoint. During this process, the designer describes how the system will be used and defines key system characteristics, drawing a correlation between activities and the functional components required to enable the system to perform the tasks. This process guides the design of the functional architecture.

The functional viewpoint helps the design engineer think through what the system has to do to satisfy the users and to meet the business objectives. A breakdown of a typical IIoT system into functional domains highlights important building blocks. This viewpoint provides a good starting point for conceptualizing the functional architecture and helps the architect see what functions can be added or left out. The IIRA breaks down a typical IIoT system into the following five functional domains:

1. control;

2. operations;

3. information;

4. application; and

5. business.

Finally, the last category—the implementation viewpoint—describes the general architecture of an IIoT system, as well as the distribution of components and the topology by which they are interconnected. This viewpoint also provides a technical description of the system’s components—including interfaces, protocols and behaviors—and an implementation map depicting the activities identified in the usage viewpoint and the key system characteristics. All these facets are guided by the business viewpoint.

These brief descriptions give you an idea of what each of the viewpoints focuses on, but the key takeaway here is that this array of tools forces the designer to look at the system’s design from a number of different perspectives. This holistic approach promotes upfront planning, prevents business objectives from getting lost in the design process and keeps key factors from falling through the cracks.

Holistic Benefits

Each of the IIRA’s viewpoints offers a unique way of looking at the design elements of an IIoT system, and often an engineer’s analysis is performed solely within an individual viewpoint. But there are occasions when the designer must consider the interactions that occur among the various viewpoints.

The creators of the reference architecture took this into consideration when they assembled the viewpoints. The IIRA’s authors arranged the viewpoints in a particular order to reflect the pattern of interactions that occurs between the four elements. Essentially, this means that decisions from a higher-level viewpoint impose requirements on the viewpoints below it (Fig. 2). For example, the decisions resulting from the business viewpoint directly influence issues being considered in the usage viewpoint.

Fig. 2: The order in which the various viewpoints are arranged, from top to bottom, reflects the flow of interactions between the viewpoints. Decisions made in a higher-level viewpoint impose requirements on the viewpoints below it. Fig. 2: The order in which the various viewpoints are arranged, from top to bottom, reflects the flow of interactions between the viewpoints. Decisions made in a higher-level viewpoint impose requirements on the viewpoints below it.

In addition, designers must contend with a class of design issues that require consideration within the context of all the viewpoints. These are called “crosscutting concerns” (Fig. 3). “Crosscutting considerations like security and safety affect all layers of every industry,” says Schneider. “It simply isn’t possible to build a functional, secure system without thinking through the impact of these issues on all parts of the system.”

Fig. 3: The IIRA’s functional domains focus on major system functions required to realize generic IIoT system capabilities. Additional functions, however, must be provided to enable major systemwide functions. These so-called crosscutting functions must be made available across many of the system functional components. Fig. 3: The IIRA’s functional domains focus on major system functions required to realize generic IIoT system capabilities. Additional functions, however, must be provided to enable major systemwide functions. These so-called crosscutting functions must be made available across many of the system functional components.

Getting Started

The decisions made across all of the viewpoints help engineers to lay the groundwork for new design projects. “By already defining relevant IIoT viewpoints, the IIRA enables architects to more easily and rapidly create their own business, usage, function and implementation views to meet their unique system requirements,” says Mark Crawford, standards strategist, Strategic IP Initiatives, SAP. “By using the easily understandable aspects of the IIRA to educate their business stakeholders and executives, they will also be able to get better input from those stakeholders during the design cycle and more complete buy-in upon delivery.”

This same global view also provides guidance when it comes to selecting components for a design. This is no insignificant benefit. IIoT products are complex systems enabled by a variety of technologies and consisting of many different components. Unfortunately, few vendors can offer a complete solution.

And, that’s where the IIRA helps. According to Shi-Wan, decisions made in the functional and implementation viewpoints enable the designer to break down a complex IIoT system into smaller functional and network components. System designers can then use this information as a guide in looking for components from various vendors in the market, both as commercial or open-source building blocks. “For example, one can look for a device management function from one vendor, an analytics solution from another and an IoT gateway from a third,” says Shi-Wan. “The IIRA provides guidance on how these functions are related to each other and how they should be integrated into a complete system.”

What’s New

To understand the IIRA v. 1.8 place in the evolution of the reference architecture, you must remember that you are talking about a “living document.” V. 1.8 generally represents incremental enhancements over its predecessor. It adds new descriptions and representations or otherwise clarifies a few key ideas and relationships, highlighting their importance or making them easier to understand.

One clarification has to do with how the reference architecture should be used. “V1.8 adds clarity to many of the concepts contained in V1.7—especially around viewpoints and the nature of the architecture patterns being representative rather than prescriptive,” says Crawford. “This was important as many organizations were under the impression that their individual architecture pattern must follow one of those specified in V1.7 rather than creating an optimized architecture to meet their own business, usage and functional requirements as expressed in their views.”

At the same time a few key additions have been made. “It [IIRA v. 1.8] brings in some new and substantive ideas, such as functional design across a compute deployment continuum, a new implementation pattern and design space considerations—all for raising awareness of important architecting concerns or providing additional representative solutions to address them,” says Shi-Wan.

V1.8 also introduces the notion of trustworthiness of IIoT systems. This encompasses the important system characteristics of safety, security, privacy, reliability and resilience — a concept well developed in the recently published Industrial Internet Security Framework.

One of the more important enhancements can be found in the introduction of the “layered databus” architectural pattern (Fig. 4). The layered databus is not a new concept to the industry. In fact, it has become a common architecture across IIoT systems in multiple industries. Tailor-made for control, monitoring and edge analytic applications, the architecture provides low-latency, secure, peer-to-peer data communications across logical layers of the system.

Fig. 4: The layered databus provides low-latency, secure, peer-to-peer data communications across logical layers of the system. At the lowest level, smart machines use databuses for local control, automation and real-time analytics. Higher-level systems use another databus for supervisory control and monitoring. Combining these systems enables complex, Internet-scale, potentially cloud-based, control, monitoring and analytic applications. Fig. 4: The layered databus provides low-latency, secure, peer-to-peer data communications across logical layers of the system. At the lowest level, smart machines use databuses for local control, automation and real-time analytics. Higher-level systems use another databus for supervisory control and monitoring. Combining these systems enables complex, Internet-scale, potentially cloud-based, control, monitoring and analytic applications.

In terms of benefits, the layered databus architecture offers fast device-to-device integration, with delivery times in milliseconds or microseconds, as well as automatic data and application discovery within and between busses. At the same time, the technology accommodates many of the requirements of automation systems, including scalable integration of sensors and actuators, natural redundancy and hierarchical subsystem isolation, enabling development of complex system designs.

“This technical design has been proven in hundreds of applications across industries,” says Schneider. “It allows IIoT systems to perform fast enough to control physical processes and scale large enough to work for industrial-grade systems.”

A Bigger Picture

As comprehensive as the IIRA is, the framework represents only part of the picture painted by the IIC for IIoT designers. Although the IIRA offers a high-level design framework, two other IIC frameworks offer more in-depth guidance in specific areas.

The Industrial Internet of Things Connectivity Framework (IICF) offers extensive analysis of IIoT connectivity issues. Not just a high-level design reference, the design framework also provides detailed, practical guidance for those building IIoT systems. The IICF crystallizes the requirements, layers, functions and considerations of a new stack architecture, and it presents a comprehensive “assessment template” for the most commonly used connectivity technologies.

On the other hand, the Industrial Internet Security Framework (IISF) dives deeper into security issues. The IISF provides a comprehensive resource for understanding IIoT security considerations. Specifically, the IISF explains how security fits within the business of industrial operations, and it defines functional building blocks for addressing security concerns, and provides implementation guidance and practical techniques for IIoT security.

As with the IIRA, these sister frameworks are the result of years of work by many experts and organizations. And like the IIRA, their relevance spans many industry verticals. Combined, the three frameworks provide design engineers with a sound starting point for IIoT system development.

More Info

Industrial Internet Consortium

Thingswise

SAP

Share This Article

Subscribe to our FREE magazine, FREE email newsletters or both!

Join over 90,000 engineering professionals who get fresh engineering news as soon as it is published.


About the Author

Tom Kevan's avatar
Tom Kevan

Tom Kevan is a freelance writer/editor specializing in engineering and communications technology. Contact him via .(JavaScript must be enabled to view this email address).

Follow DE
#16739