By now, we’re all aware of the transformational change that’s before us. We have thousands, perhaps millions of connected things, the seemingly infinite tentacles of the IoT/Industrial IoT (IIoT) infrastructure, and floating above it all, the promise of the cloud.
So much technology. So little time.
There’s no question we’re at the cusp of cataclysmic change in our industry, driven by strategies requiring all devices to be connected to each other and to the cloud. And as we move forward, these connected devices and their associated systems are becoming extremely complex.
This connectedness of things is not a new concept. Back in 1968, when Dick Morley invented the programmable logic controller (PLC), and the subsequent ladder-logic programming gained acceptance, it ushered in a new era of industrial automation. And not too long ago, supervisory control and data acquisition (SCADA) and fieldbus technology helped to truly revolutionize the industrial automation movement.
Today, everything needs to be connected. All of a sudden there are gateways, 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.
Now add to the equation people who are trying to solve problems on the software side: commercial middleware vendors; user groups and consortia dedicated to communications protocols; cloud providers; semiconductor companies; and, of course, security solution providers. You wind up with an entire ecosystem of players at the ready.
And so as the number and types of connected devices increase, IoT topologies evolve and the complexity of implementing an IIoT system becomes a very real problem. In fact, the Penton/Informa survey below (Fig. 1) captures the state of IoT/IIoT fragmentation as reflected by the feedback from the survey respondents. While it’s no surprise the top two concerns are security-related (which I won’t address in this article), the balance of top issues is reflective of the fragmentation, which translates to increased risk, cost, and lost business opportunity.
1. Here’s a list of the main IoT adoption inhibitors, as indicated by survey respondents. (Source: Informa)
But let’s be pragmatic: How can anybody know everything about all the different solutions? As I’ve argued, it’s all very fragmented, and the costs are increasing (particularly with the many devices that need to be enabled, connected, ported, scaled, and integrated for cloud connectivity) under the umbrella of an ever-growing ecosystem of solutions and suppliers.
No question, there are gaps in the different solutions and a lack of standards. Again, it's all very fragmented. But it’s not all bad news. For example, we’re starting to see the industry coalesce around certain standards such as Message Queue Telemetry Transport (MQTT) for connectivity on top of the TCP/IP protocol and HTTPS for secure connectivity over HTTP.
So how do we turn the corner? From my interactions with many partners and customers, here are some problem areas we need to address when it comes to IIoT fragmentation.
Comprehensive Device Management
Device management is a core requirement for an effective IoT strategy. The bottom line is how do you manage all of your connected devices? How do you onboard and authenticate to ensure all connected devices are authorized to participate in your cloud infrastructure? How do you accomplish even relatively simple tasks like configuring the device for basic operation (naming it, setting the right language and time zone, etc.) and execute basic control commands like remote reset, configuration download, and restore factory defaults?
Then you must consider 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 up and down—and across your entire IoT infrastructure.
Unknown Clouds
One truth is evident from my many discussions with equipment manufacturers who are selling to businesses: They cannot predict what cloud their equipment will be integrated with. Take, for example, a robotics company selling to automotive manufacturers. Do all automotive makers use the same cloud? Potentially, but it’s not likely. Even in 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 yet 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 that then requires a custom implementation.
2. An open and expandable IoT solution is needed now more than ever. Most cloud SDKs don’t address the device software complexity and scalability problem.
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 is a controller. Because each device has a specific purpose and set of requirements, every one of these devices turns into a custom implementation.
For instance, the smart sensor device might need to run on an Arm Cortex-M4 with an open-source RTOS as its designated operating system. The gateway device might require the full service capability of commercial Linux on top of an x86 application processor. And the controller device might need to run a safety-certified operating system like the Nucleus RTOS on an Arm Cortex-A53 application processor.
Every one of these devices, regardless of the OS, processor architecture, or processor class, requires the integration of similar functionality that includes device management, cloud backend integration, and security. The result is every connected OEM device becomes a purpose-built custom implementation, every single time. The ultimate goal would be to have a solution that can scale across platforms, maximize code reuse, and minimize re-engineering of solutions.
Where is our “aha” moment?
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 up to cloud backend integration.
One of the common discussions I have with customers right now is this idea of portability and reuse. A host of IoT devices (e.g., gateway edge devices) are based on x86, but my customers are saying, "You know, we're considering Arm quite seriously now." So, to be able to port from x86 to Arm is really important when we’re talking about a legacy IIoT moving to adapt to new technology. Customers also want to reuse their IoT-enabling investments and scale down to microcontroller-based devices, and port across different or multiple operating systems, too, whether it’s an open-source or commercial RTOS, open-source Linux, commercial Linux, and so on—without sacrificing security.
So I ask my colleagues and the industry at large, “Where is our silver bullet? How will we address this nasty side effect of IIoT fragmentation?”
Warren Kurisu is the director of product management in Mentor’s Embedded Systems Division, overseeing the embedded runtime platform business for the Nucleus RTOS, Mentor Embedded Linux, virtualization and multicore technologies, safety-certified runtimes, IoT, graphics, and development tools.
Reference:
