Architectural considerations for enabling industrial IoT devices -

Architectural considerations for enabling industrial IoT devices

The Industrial Internet of Things (IIoT) is a transformative technology. Implementing, deploying, and maintaining such an infrastructure can be a tricky proposition at best. A successful implementation is more than device connectivity and security, it’s also about expanding the breadth and depth of all connected devices, providing additional value for the user with increased profitability and growth.

To achieve this goal requires careful preparation and a thorough understanding of what today’s IIoT technologies have to offer.

Available enabling technologies consist of a few comprehensive cloud platforms with their associated device enablement software development kits (SDKs), along with a host of commercial and open source runtime components and cloud backend applications.

This article touches on a few key architectural considerations required for the successful operation of IIoT devices with a focus on the software that runs on the device.

Industrial IoT Enablement

The major goals of an Industrial IoT implementation are: 1) to securely connect end node and edge/gateway type embedded devices to a cloud backend; 2) collect data from these devices, and visualize/analyze or present this data in a meaningful manner; and 3) to offer a means in which to interact, configure, maintain, and upgrade the devices using a cloud-based infrastructure.

To better understand how a smart device interacts with the cloud, or more specifically, the cloud backend services, let’s take a look at a few basic steps a typical smart device might take

Step #1 – Secure onboarding
This begins with the secure boot of a device. In this initial stage, the boot process must sequentially authenticate the boot loader, operating system software, and other software components which are all executed as part of the boot sequence. Post secure boot, the device needs to securely onboard itself with the backend. Cloud platforms provide comprehensive infrastructure that allow for identity management and authentication of devices trying to onboard onto the system.

Step #2 – Configure, monitor, and control
Once the device is onboarded, the next step is for the device runtime to instantiate and expose the parameters and services supported by the device to the backend. This is accomplished using a “data model” or a standardized “object model” which is compatible with the cloud backend infrastructure.

Step #4 – Secure telemetry 
After the data or object model has been established between the device and the backend, the device pushes the data up to the cloud and receives asynchronous messages from the cloud. Securing data in motion is a table-stakes requirement in the IIoT. Transport Layer Security (TLS) and Secure Socket Layer (SSL) are typically employed to establish a secure connection and encryption of data exchanged between the device and the backend.

Step #4 – Software updates and maintenance
This is a key attribute toward achieving reliable operations from cloud-connected devices. In order to fix bugs, upgrade functionality, and patch security issues, a comprehensive infrastructure to manage device firmware, applications, and data is critically important.

Embedded Devices in Industrial IoT

IIoT devices can be categorized as end nodes, which are located in the lower tier of an IIoT ecosystem, and edge nodes which often serve as a gateway between the end nodes and the cloud backend. End nodes are commonly actuators, sensors, controllers, human machine interfaces (HMIs), etc. In some cases, end nodes will connect directly to the cloud without the use of an edge node/gateway.

Although both end nodes and gateways are embedded devices they can vary significantly in form factor and functionality. End node devices can be quite small. Often they are 8- or 16-bit smart sensors that utilize simplified wireless protocols and extreme power management strategies to harvest local energy for maintenance-free operation. On the other end of the spectrum, edge nodes can be powerful multi-processor, multicore devices with enterprise/server-like computational power. From a software perspective, end node devices can run on bare metal (no operating system) and for larger devices, a real-time operating system (RTOS) or even a general-purpose operating system (GPOS), such as a Linux®, are often deployed.

An example component architecture for runtime software for an edge node, or cloud-connected end node, is shown in Figure 1. The diagram depicts a typical architecture that consists of a cloud vendor-provided SDK for the device and other OS/System services needed to fulfil the device management needs for the connected device.

click for larger image

Figure 1: A device software IIoT architecture comprises a cloud SDK for backend services and OS/system services available in the OS runtime environment. (Source: Mentor)

Cloud Platform and SDK-provided Functions for Device Management

Cloud vendors provide a variety of infrastructure and tools to create and manage connected IIoT devices. One of the primary functions cloud vendors offer is the means to securely onboard a device and the communication infrastructure needed to monitor, manage, and update that device. However, specific capabilities vary from one provider to the next.

Some of the core functions you can expect from established cloud vendors include:

Device Identity management and provisioning
Cloud platforms typically provide the infrastructure needed for users to add, remove, and manage devices and associated security attributes. When a user adds a new device, an identity for the device is created in a device registry hosted on the cloud and associated security credentials are generated. These credentials need to be provisioned to the device to enable secure onboarding onto the cloud platform. In typical environments, public key-based mutual authentication is used to establish a robust device authentication infrastructure.

Cloud vendor-provided device SDKs include a suite of communication protocols supported by the vendor’s cloud platform. On top of this protocol suite layer sits a cloud vendor-specific layer which enables higher order of constructs that may include platform-specific bindings to instantiate device data models, APIs to define and negotiate a device twin, etc.

Data model
When the device comes up, a data model must be negotiated between the device and the cloud backend. There are several approaches:

A custom data model approach is supported by cloud platforms like Microsoft Azure and Amazon Web Services (AWS), where by using platform-specific bindings provided by the device SDK, the device can define and expose its data model to the backend.

A Standards-based, object model is another approach. An example here is the Lightweight Machine-to-Machine (LwM2M) protocol, which leverages the efforts made by the OMA standard and IPSO Alliance. (The IPSO Alliance is an industry consortium that supports LwM2M by publishing a vast set of bindings for smart objects such as sensors and actuators, device firmware, to industrial machinery, etc.) Since the objects have standardized bindings, they can connect to any cloud infrastructure that conforms to the same object model.

Other Device Software Functions Needed for IIoT Device Management: OS/System Services

OS/System services expand on the foundation of device onboarding and communications provided by cloud vendor SDKs. These services fulfill the functions necessary for Industrial IoT devices enabling comprehensive device management of IIoT devices. The functions include life cycle management, system/device health monitoring, device software updates, device application updates, etc.

Some of the key functions OS/System services enable include:

  • Software updates services
    The ability to update device operating system (OS) software and application software is an essential element of IIoT smart device enablement. Security is an important tenet when it comes to delivering OS and app updates to the device. Most use cases require privacy, integrity, and authenticity attributes be confirmed before an update artifact is consumed by a device. The device software architecture should take into consideration infrastructure needed to assess firmware health and support a fail-safe roll-back function to a known working firmware version. Application updates to devices can be delivered as encrypted/signed binary packages. In the case of Linux- or Windows-based devices, container-based application management is becoming extremely popular. A container-based approach for application management provides numerous benefits including portability, ease of migration, scalability, standardization, continuous integration (CI) and delivery (CD), and the availability of a strong open source ecosystem of runtime components and tools for management and orchestration of container-based applications.

  • System diagnostics, health monitoring, and profiling services
    IIoT devices deployed in manufacturing environments have to be monitored for system health and performance. In post-mortem debugging scenarios, the ability to profile applications on the device can provide deep insights into the device software runtime and assist with troubleshooting deployed devices.

  • Secure system services
    In IIoT environments, the convergence of Informational Technology (IT) and Operational Technology (OT) networks has made security of paramount importance. The device runtime should provide the security infrastructure needed for hard isolation of the IT and OT network interfaces so that an external Internet attacker cannot compromise the internal factory network. Suitable firewalls and edge network configuration tools should be employed to enable this isolation.

The Integration of a Cloud SDK with OS/System Services

To fulfil the complete potential of the Industrial IoT, devices must be able to offer the full set of runtime functionality already discussed. Figure 2 is an example of a commercial software framework that addresses these demands and requirements. This particular IIoT framework integrates the functions and capabilities of a vendor-provided cloud SDK with the OS/system services needed for comprehensive device management.

click for larger image

Figure 2: The Mentor Embedded IoT Framework (MEIF) architecture integrates the capabilities of a cloud vendor SDK with OS/System services to offer a comprehensive end-to-end IIoT solution. (Source: Mentor)

The Mentor® Embedded IoT Framework (MEIF) is a new product from Mentor, now a Siemens business. MEIF supports multiple cloud platforms including Amazon Web Services (AWS), Microsoft Azure, and soon Siemens MindSphere and others. The MEIF architecture also supports Eclipse IoT-based back-end applications on the cloud. It’s important to understand that Mentor’s solution does not replace technologies and investments already provided by a cloud vendor; rather, it aims to fill the gaps between the provided functions of cloud vendor SDKs and the required device functions for comprehensive device management in IIoT environments.

For more detailed information on the IIoT productivity gaps alluded to in this article, please read the following white paper, “IIoT Evolution: An Approach to Reuse and Scale Your IIoT Technology Investment“. For specifics on Mentor’s IIoT framework, please visit the Mentor Embedded IoT Framework website.

Arvind Raghuraman is a senior architect for the embedded platform solutions group at Mentor, now a Siemens business. He is a software architect with background and expertise on several Mentor products including; Mentor® Embedded Hypervisor, Mentor® Multicore Framework, Nucleus® RTOS, and development tools. Arvind has over 15 years of experience spread across developing systems and solutions for industrial automation, and software products and solutions for embedded systems. Arvind has his MS degree in Electrical and Computer Engineering from Auburn University, USA.

2 thoughts on “Architectural considerations for enabling industrial IoT devices

  1. “Considering how many moving parts there actually are when it comes to IoT – basically everything is trying to talk to each other – of course there has to be more points of monitoring and management so as to ensure that everything runs smoothly during oper

    Log in to Reply
  2. “Of course there needs to be a higher level of protection when it comes to industrial uses for IoT framework. It's important to make sure that these company systems are not compromised considering the greater implications of the whole system going out of s

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.