Architectures that help implement the Industrial Internet of Things

Among the models available to implement the Internet of Things, two standards bodies, the Industrial Internet Consortium and oneM2M, offer complementary architectural approaches. Here’s a look at each, and how they work together.

STAFF REPORT

Successfully implementing an Internet of Things solution requires expertise in a number of areas. Not all companies have such expertise so collaboration with members of an IoT ecosystem is often necessary. Two organizations, the oneM2M and the Industrial Internet Consortium (IIC), are collaborating to “drive global scale in standards development and avoid standards balkanization,” notes a recent paper from the IIC.

The IIC has been working to help accelerate the adoption of the Industrial Internet of Things (IIoT). In 2018, the IIC joined with the OpenFog Consortium (OFC) to advance edge computing in IoT applications.

COMMON POINTS

The IIC offers the IIRA standard as an architecture framework template and methodology for users to identify architectural concerns, concepts, and patterns. The IIRA standard consists of several perspectives, many of which work well with the oneM2M standard:

• The business viewpoint is not commonly found in IIoT architectures, including oneM2M. IIoT designers who leverage the oneM2M common service layer may benefit from the analysis of business concerns as described in this viewpoint.

• The IIRA functional viewpoint describes domain and crosscutting functions for IIoT systems end-to-end. oneM2M defines functions common across industrial verticals. It uses service abstraction within middle layer services to hide device layer complexity and bridge applications to devices.

• A number of synergies between IIRA and oneM2M show up in the implementation viewpoint. Users can follow the IIRA architecture patterns and use oneM2M common services to support those patterns.

• Functional components not covered by the common service layer can be part of the application layer components in oneM2M and developed for a specific IIoT system. oneM2M common services can be shared by different industrial verticals, enabling interoperability across these verticals.

From a system-usage analysis perspective, the IIRA usage viewpoint provides a way to analyze how the system is to be used to achieve its objectives.

ONEM2M

oneM2M is a global standard defining a common service layer with a set of services required by IoT systems regardless of industry. These services help application developers focus on building, deploying and commercializing their IoT applications.

The oneM2M organization has 200 active members. One of its goals was to develop a common service layer with the IoT. This layer sits between applications, networks, and aids functions that are needed across different industry segments.

This common service layer functions as a layer between an application’s business logic and the communications network. It helps connect end-point devices and sensors. It also makes it easier for users of oneM2M specifications to integrate, design and manage stack technologies of multiple IoT applications within a company or in different industry verticals.

This service layer consists of a three-layer architecture that consists of applications, a common services layer (middleware), and networks. The interfaces between these layers have a standard format to enable a secure means for connecting data producers and data consumers. In particular, Machine-to- Machine (M2M) and IoT applications will likely need a common service layer such as this.

This layer’s functions include device management, registration and security. According to the IIC paper, the layer “horizontally joins the middle layers of several separate, heterogenous, vertical IoT solutions, to share common capabilities and ensure reusability and economies of scale.”

A key aspect of this horizontal architecture is enabling cross-silo interoperability. Thus, individual IoT solutions can share data and resources through common service layer functions. One result is that developers can easily share data between applications and reduce dependence on single-vendor products.

Both the oneM2M and IIC architectures use similar technologies. They connect to various communication systems such as the web and RESTful services, Data Distribution Service (DDS), OPC UA) and computational technologies, such as cloud computing, big data and machine learning. Thus, some of the specifications’ elements map to each other. But there are differences in focus and approach. Here’s a closer look.

IIC’S IIRA

The IIRA helps users rapidly install interoperable IIoT systems. It identifies and highlights important architectural concerns, concepts and patterns applicable within and across industrial sectors that might interfere with interoperability.

The IIRA suits system implementers, where it functions as a starting point to shorten system development. It makes use of reusable, commercially available, or opensource system building blocks. Many industrial sectors can take advantage of IIRA, including manufacturing, transportation, energy, agriculture, healthcare and others. IIRA helps reduce the cost of design and operations by giving users a common language.

This standard addresses communication architecture concerns with vocabulary, structures, patterns and a methodology. It adapts architectural concepts, constructs and approaches from the ISO/IEC/IEEE 42010- 2011 Systems and Software Engineering— Architecture Description standard. A goal is to clarify how such a framework can help create the reference architecture, and then help create IIoT architectures.

According to the paper, architectural concerns are identified and classified into four viewpoints per the ISO/IEC/IEEE 42010- 2011 Systems and Software Engineering— Architecture Description.

These viewpoints are:

• The business viewpoint identifies stakeholders and their business vision, value and objectives of an IIoT system. Business decision-makers, plant managers and IT managers can use this perspective to better understand and drive IIoT system development for business goals.

• The usage viewpoint describes how the IIoT system will deliver the intended business objectives.

• The functional viewpoint focuses on the functional components and structure to support the intended uses. It defines the domains most important to consider in an IIoT system and clarifies the relationship between them along with cross-cutting functions that must be available across many of the system components.

• The implementation viewpoint determines the technologies needed to implement functional components, their communication schemes and their lifecycle procedures.

The IIRA defines system characteristics as system properties and behaviors. It bases its definitions on an IIoT system’s constituent subsystems, their interactions, and the environment in which they operate. For example, one system characteristic might be trustworthiness, which can include safety, security, privacy, reliability and resilience. Other system characteristics examine how the IIRA functional domains work with other systems ranging from edge to cloud as IIoT architectures evolve.

Even though IIC and oneM2M take different approaches in dealing with IoT and IIoT challenges, they share a common objective of ensuring interoperability and reusability. The common goal is to reduce the complexity and costs of designing, developing, and deploying IoT systems.

ONEM2M ARCHITECTURE

A common method of implementing IoT in applications is to use silos in a vertical solution stack. However, this method does not always scale well or handle resource reuse well.

In an IoT application, if a device management function is implemented for a narrowly defined use, this could easily prevent its

reuse for a second or third IoT application. The same logic applies to other service enablers necessary for the deployment and management of IoT applications. o

neM2M addresses this by using a horizontal model based on a common services layer. This layer includes communications management, device management and security functions. It makes devices and their data discoverable and accessible to more than a single parent application. One benefit of this approach is that it doesn’t lock users with one vendor.

The common services layer is standard on oneM2M and includes specifications for end-device and gateway entities. Users can deploy native oneM2M systems, which comprise oneM2M compliant end-devices communicating with one or more oneM2M platforms. Users can also choose systems that include a mix of oneM2M and proprietary devices. Such an approach may involve interworking proxy gateways to manage non-oneM2M devices communicating with a oneM2M platform.

Functionally, oneM2M defines fourteen common service functions (CSFs). These relate to network connectivity, device security, transport protocols, content serialization, IoT device services and management and IoT semantic ontologies.

Developers can use each service to focus on application-specific functions, such as turning a switch on or off. Abstraction techniques can be used to mask the underlying technology specific details, and allow the use of different communications stacks and protocols such as HTTP, CoAP and MQTT. For example, a switch might use a fixed or Wi-Fi network, a CoAP or HTTP transport. It might use a JSON or XML serialization technique, an Open Connectivity Foundation (OCF) or thread service, or an ontology based on Smart Appliances REFerence (SAREF) or W3C’s Thing Description.

oneM2M offers security-related APIs to simplify security for devices and applications to secure IoT devices and prevent and mitigate attacks. This standard is constantly evolving to address new IoT requirements.

IIRA AND ONEM2M — WORKING TOGETHER

The IIRA organizes an IIoT system into functional domains and crosscutting functions. The functional domains focus on major system functions that support generic IIoT usages and IIoT system capabilities. The crosscutting functions should be made available across many of the system functional components.

oneM2M centers on the crosscutting design approach. It supports a software framework for linking IoT applications to value-added services relating to network connectivity, device security, transport protocols, content serialization, IoT device services and management and IoT semantic ontologies. With these services, application developers can focus on application-specific functions without worrying about the underlying technologies.

The oneM2M common service layer functions are:

• Functions in the business, information and application domains, along with crosscutting functions, industrial analytics, and intelligent and resilient control. These are also available in the IIRA standard.

• The security functions considered in the IIRA System Characteristics corresponds to the security function in the oneM2M service layer.

• Functions in the operations domain and in the distributed data management in the crosscutting functions in the IIRA map to functions in the oneM2M common services layer. These are registration, discovery, device management in oneM2M common services layer.

• Functions belong to the IIRA distributed data management map to the oneM2M data management and repository.

• In the IIRA map, functions in the connectivity in the crosscutting function in both the common services layer and the devices (layer) correspond across the network spans in the oneM2M horizontal architecture. The IIRA connectivity functions directly map to semantics, communication management, network service exposure and transaction management.

• Functions in the control domain and the physical systems in the IIRA map to those belonging to things in the one M2M horizontal layer.

Other functions in the oneM2M services layer not mentioned may not be described directly in the IIRA or they belong to its lower layer functions.

A common IIRA architecture pattern often consists of elements arranged in three tiers—edge, platform and enterprise. The edge tier includes an edge gateway communicating with three devices through a proximity network. Data and control pathways use a service network to link the platform and enterprise tiers.

An Application Entity (AE) is available for each connected sensor and data source. AEs use a standard application service logic in individual devices, gateways and sensors to deliver a standard interface to manage and interact with applications.

In a distributed architecture, oneM2M’s common services layer resides in Common Services Entities (CSEs). CSEs control when communications occur, taking into account any time sensitivity for the data. Developers can embed CSE function in a gateway to place common services closer to the edge of an IoT installation. A complex IoT installation can involve several gateway CSEs interoperating with a cloud-based CSE.

Finally, an AE is needed for the domain application in the enterprise tier. The AE will interact with edge devices and sensors.

AEs and CSEs offer a standard way for devices and sensors to function in a network-agnostic manner. They hide the complexity and heterogeneity of network usage from applications, which helps simplify implementation for application developers.

INTERWORKING

According to IIC, the introduction of machine-to-machine solutions into industrial IoT applications is progressing in three phases. Rather than a typical master/ slave architecture, users link multiple proximal networks through cloud-based data aggregation and supervisory control systems. As the IoT market matures, applications will use distributed architectures. As large-scale deployments emerge, architectures will need new and standard enablers that interlink multiple sub-systems to peers and to central cloud systems.

Fundamental to successful implementations is the selection of a core connectivity standard to bridge applications and devices in an IIoT system. The IICF identifies potential standards for core connectivity with detailed assessment templates to evaluate connectivity technologies. These templates will help developers choose a IIoT compatible core standard that fits the application.

A core connectivity standard requires standard mappings (i.e. bridges) to other core connectivity standards as referred in the IICF. Core gateways are the means used to implement these standard mappings. This approach limits the number of core connectivity standards, reducing complexity.

The gateway functions may be simple bridges converting data and protocols between connectivity core standards, or they may include more complex edge computing functions. Edge processors can perform analytics, data reduction, artificial intelligence, machine learning, security processing, storage and other functions. They convert between core connectivity standards and process the data that passes through the gateway functions.

The IICF recommends that system architects select a framework-layer standard for core connectivity. A framework-layer standard (e.g. DDS, OPC-UA, Web and RESTful Services) provides the ability to exchange data. It standardizes the format of the communicated data and provides more data handling and communication management capabilities over lower-level transportlayer standards (e.g. MQTT, CoAP, HTTP). The IICF provides detailed assessments of several frameworkand transport-layer standards to help system architects choose the best connectivity technology for their needs.

The IICF addresses syntactic interoperability, but not the data or information model standards needed to address what the data means, or its context; for example, is a data reading about temperature or pressure? The IIC is working on information model guidance for future publication. oneM2M, however, addresses the need for standard information models and bridging or translating between different framework layer standards.

The goal of the standardization roadmap for oneM2M is to provide a protocol abstraction layer on top of multiple connectivity technologies. It will complement and interwork various proximal industrial communication technologies (e.g. DDS, OPC-UA, WirelessHART, IWLAN) to the internet. This permits the use of established standards from the fixed-network, mobile-network and internet sectors (left-hand side of illustration) to be applied in support of applications from the industrial sector, smart homes and eHealth, for example. It maximizes the re-use of established industry standards.

In light of their respective organizational goals, the IIC and oneM2M will continue to foster the development of IoT and IIoT markets. Following the joining of forces between the IIC and OFC, the IIC will expand its effort to clarify distributed computing at and near the cyberphysical boundary of IIoT systems and continue to provide an ecosystem for the advancement of the IIoT.

The source for this information was a paper from the Industrial Internet Consortium and oneM2M.