Tackling IoT system interoperability
IoT application development has already evolved largely into an integration problem. Developers can find all manner of IoT hardware devices that provide a growing number of near drop-in solutions for populating an IoT system's layers of terminal sensor nodes and edge computing devices. Developers can similarly find solutions designed to fill those layers with software -- from RTOSs in the periphery, high-performance Linux at the edge, and any manner of software running on the cloud's virtual servers. In practice, of course, building an IoT application requires significant effort in making all of those pieces function as a single system and application while ensuring end-to-end security, availability, and reliability. Worse, large-scale enterprise IoT systems need to do this multiple times as they combine separate, specialized IoT systems into a functional whole. That's a challenge facing many enterprise-level IoT developers -- and one Mentor Graphics hopes to address with its Embedded IoT Framework.
This notion of a network of IoT networks is a key requirement for success at the enterprise level. Mentor Graphics cites a view by McKinsey that 40% of the potential value of an IoT application depends on successful integration of multiple IoT systems. Integration of even one IoT system is work enough: Mentor notes a forecast by Gartner that in the near term, half of the cost of implementing IoT systems will be spent on integrating their individual components. Unlike IoT platforms, which are intended to simplify vertical integration of hardware to cloud systems, Mentor's IoT framework seeks to ease both vertical and horizontal integration of systems implemented on various IoT platforms such as the Amazon Web Services (AWS) IoT Core, Microsoft Azure IoT Hub, and others.
Frameworks have a long and somewhat tortured history in the electronics industry. Years ago, EDA companies including Mentor introduced comprehensive frameworks intended to simplify the integration of individual design tools from multiple providers into a "seamless" work flow. The problem then was not unlike what enterprise IoT developers face today. Of course, AWS and Microsoft Azure bear little resemblance to the point-tool providers of the EDA era. As far as the enterprise IoT developer is concerned, however, they are similar in that they provide just one piece of a larger, multi-system puzzle. What's relevant here is the history lesson from those earlier frameworks: Despite heroic efforts, those EDA frameworks failed because they went too far, attempting micro-level integration. The added layers of software meant to normalize data, manage tool work flows, and support other design tasks paradoxically delayed availability of actual, workable integrated production design flows.
With its IoT framework, Mentor took a different approach. Here, the company avoids inserting itself between the developer and IoT platforms such as AWS's and Microsoft's. Rather than attempt to provide a single software interface to all IoT platforms, the Mentor Embedded IoT Framework seeks to fill the existing implementation gaps that lead to the kind of costs that Gartner describes. In this framework, IoT platform SDKs are there, untouched, available for native use by the developer, but supplemented by services designed to fill the gaps (Figure).
Figure. The Mentor Embedded IoT Framework intends to supplement commercial cloud SDKs with services needed to fill existing gaps in the implementation of enterprise IoT applications. (Source: Mentor Graphics)
One of the implementation gaps that Mentor addresses relates to software updates. Although cloud providers support basic functionality for compiling and downloading a file, the cloud-level service typically lacks detailed information about device bootloader function, for example. Consequently, developers are left to create additional device-level services to define the specific actions required to safely deploy a software update package. Mentor fills the gap by providing more complete software-update services.
That's not to say that the Mentor Framework doesn't sometimes provide more generalized alternatives to the cloud vendor's solution. For example, AWS Greengrass lets IoT developers migrate portions of their cloud services to edge devices, using AWS Lambda functions to provide some cloud functionality even when the cloud connection is lost. Greengrass is a unique service that provides an important capability, but it remains an AWS-specific service. To add application- or service-level software to edge devices through a more general approach, developers could use industry-standard Docker containers to encapsulate and deploy their software. With the Mentor Embedded IoT Framework, developers can use either approach: AWS Greengrass with Lambda functions or use the framework's support for Docker to deploy containerized software.
The Mentor Embedded IoT Framework initially supports AWS and Microsoft Azure IoT platforms with planned support for Siemens, IBM Watson, and others. For more information, view the Mentor video or visit the Mentor Embedded IoT Framework site.