A New Approach To A Fragmented Industrial IoT

Connecting millions of devices will require overcoming major obstacles.


By now, we’ve all seen or experienced the transformational change the Internet of Things (IoT) has had in our daily lives. The emerging area of industrial automation, often referred to as the Industry Internet of Things (IIoT) or Industrie 4.0, has also quickly transformed itself. Suddenly within IIoT we have thousands, even millions of devices, connected to the seemingly infinite potential of the IIoT infrastructure, and the promise of what cloud computing might bring.

Today everything in the IIoT world must now be connected. There are gateways, assets, edge devices, smart sensors, dumb sensors, end nodes – even local servers – all of which, to some degree, are tasked with collecting, aggregating, processing, and sending data.

Major obstacles still persist
As the number and types of connected devices increase, IoT topologies evolve and as a result, the complexity of implementing an IIoT system becomes a very real problem. It’s this paradigm of growth, complexity, and a variety of established players that has exacerbated the fragmentation of the IIoT.

A recent survey by Penton Media captures the current state of IoT/IIoT adoption concerns (Figure 1). While it’s no surprise the top two concerns are security related, the balance of the issues are closely linked to IIoT fragmentation. This fragmentation can lead to increased risks and costs, wasted resources, and lost business opportunities. But seriously, how can any one person or a single company know everything about all the different solutions out there? No question, it’s all very fragmented, and the costs are increasing under the umbrella of an ever-growing ecosystem of solutions and suppliers.

Figure 1: IoT adoption inhibitors. Source: Penton Media.

So how do we turn the corner? A few problem areas the industry needs to address if we are to combat IIoT fragmentation include:

Device management
Comprehensive device management is a core requirement for any IIoT strategy. The bottom line is how do we enable users to easily and effectively manage all of the connected devices on a given IIoT system? How do you onboard and authenticate to ensure all connected devices are authorized to participate in the cloud infrastructure? How do you accomplish even relatively simple tasks like configuring the device for basic operation (naming it, setting the local language and time zone, etc.) and execute basic control commands like remote reset, configuration download, and restore factory defaults?

Then there are more complex operations such as device updates and maintenance, which include application enablement, OS updates and patches, firmware rollbacks, and fleet rollouts. And, of course, all of this must be done in a secure and comprehensive fashion north and south – and horizontally across the IoT infrastructure.

Unknown or changing clouds
A known fact when you talk to equipment and/or device manufacturers who are selling their products to the end customer is they cannot predict which cloud their equipment will ultimately be integrated with. Take, for example, a robotics company selling to automotive manufacturers. Do all automotive makers use the same cloud? It’s possible, but not likely. Even when talking to companies who manufacture their own equipment for their own businesses, the cloud decision is subject to change. This gives rise to several questions. How do I design and manufacture my equipment so that it can be integrated with whatever cloud environment is being used? How am I dependent on embedded SDK components provided by the cloud vendor? How can I maximize the reuse of my investment? Once again, this is another expression of the practical problem created by industry fragmentation.

Scalability and reuse
Because of the complexity and types of devices, and the evolving topologies required to implement business strategies, a cookie-cutter formula to implement an IoT architecture does not exist. Invariably, for each device there’s a different target platform which then requires a custom implementation. To illustrate this point, let’s take a look at Figure 2. Here we have a basic rendering of an IIoT infrastructure. Let’s say the light blue box represents a smart sensor, the green box is a gateway, and the brown box a controller. Because each device has a specific purpose and set of requirements, every one of these devices turns into a custom implementation. The smart sensor device might run on an Arm Cortex-M4 with a proprietary or open source RTOS as its designated operating system. The gateway device might require the full service capability of a commercial Linux on top of an x86 application processor. The controller device might need to run a safety-certified operating system such as the Mentor Nucleus RTOS on an Arm Cortex-A53 application processor.

Figure 2: The need for an open and expandable IoT solution. Most cloud SDKs today do not address the device software complexity and the much-needed scalable operability functionality.

Every one of these devices, regardless of the operating system, processor architecture, or processor class, requires the integration of similar functionality that includes device management, cloud backend integration, and security. The result is each connected OEM device becomes a purpose-built custom implementation every single time. The ultimate goal, then, is to have a solution that can scale across platforms, maximize code reuse, and minimize re-engineering of solutions.

Introducing an industry solution
Certainly, if we plan to address the current issue of fragmentation, we need to find a more standardized approach when it comes to end device implementation and cloud backend integration. What’s needed is a type of software framework that not only complements but extends the massive investments made by today’s cloud vendors, which allows connected devices to be implemented down to the hardware of edge or end node devices.

Figure 3: The Mentor Embedded IoT Framework addresses industry fragmentation by complementing and extending cloud vendor SDKs, enabling such services as device management down to the edge node.

The Mentor Embedded IoT Framework (MEIF) is Mentor’s new IIoT solution enabling device manufacturers to address fragmentation issues, and in the process, deliver solutions to their downstream customers effectively and efficiently (Figure 3). The framework does not replace technologies and investments already provided by cloud vendors; rather, it complements and extends those technologies by integrating their features with the edge or end node OS/hardware device platforms. For example, cloud vendor SDKs enable file download, but a software update mechanism also needs to download related information and instructions (metadata), version numbering and control, roll-back facilities, etc. – all of which are enabled by MEIF.

Mentor’s MEIF enables integration of cloud-vendor provided embedded SDKs (dark grey in Figure 3) alongside a well-defined set of MEIF device APIs (light blue in Figure 3) which can be extended as needed. Through this framework approach, MEIF minimizes costs related to learning, implementation, and porting of smart devices ranging from powerful gateways to smart sensors.

IIoT fragmentation is a very real problem. Mentor’s new MEIF addresses many of the challenges fragmentation creates and helps device manufacturers tap into the true potential of the IoT/IIoT.

Please visit the Mentor Embedded IoT Framework page for more details. You can also visit Mentor’s Industrie 4.0 website for more information on Mentor’s involvement and current IIoT initiatives.

Leave a Reply

(Note: This name will be displayed publicly)