Breaking down the silos to enable full potential of IoT

IoT is following in GSM’s standardization footsteps

The market for voice communication and wide-area connectivity sits on top of a rich ecosystem of industry partners. The IoT market is less advanced, with only parts of what will be an efficient, standards-driven ecosystem developed so far. This is currently one of the main obstacles for the IoT story.

Today, there are plenty of standardized wireless and wired technologies for IoT connectivity within different verticals, including LTE-M, NB-IoT, 2G, Bluetooth, Wi-Fi, 3G, LTE, Ethernet, Profinet and so on. However, interoperability on higher protocol layers largely depends on proprietary technologies.

In practical terms, IoT customers and integrators can use connectivity from any network operator or select any radio module. However, it’s almost impossible for them to choose or develop devices independently of the platform they use for device and application management functions. As a result, end users are left with siloed applications, which in turn results in the loss of benefits such as data and vendor interoperability.

IoT platform essentials

Looking at the reference architectures of IoT platforms, most of them provide the basic functions that are common for many IoT use cases. These include functions for device management, security, registration, group services, subscription and notification services, etc.

Although these common functions share the same names, individual implementations differ in the absence of standardization. In addition, differences in protocol usage prevent device interoperability across different platforms.

Obstacles to IoT interoperability

To realize the full potential of IoT, “things” need to talk to and understand each other. An even greater obstacle to attaining this outcome is the different data models employed within the countless different proprietary implementations.

For instance, if someone was to call an end user on their phone and speak in Swahili, most users would probably not be able to communicate or achieve a meaningful result.

The same issue occurs in communication between things when they use implementation-specific data models.

Today, each vertical industry comes along with its own fora and specifications bodies to develop data models for its own vertical. This is quite natural.

For example, in the industrial automation industry, organizations like OPC are working on data models and objects which can be used on the shop floor. In the automotive industry, ETSI’s Intelligent Transport Systems technical committee is working collaboratively to define messages and data models for communication between cars.

Many IoT applications also involve several partners in a distributed value chain. For instance, an intelligent application for an industrial plant might automatically order feedstock from one or more partners for its production line. Supplies are typically ordered and delivered by several partners spanning the industrial and transportation domains. It is easy to see how this scenario can end up in up in an “island of things” configuration, since different partners in the value chain belong to different verticals, each with their own specific data models.

How oneM2M standardizes interoperability

This is where the oneM2M standard comes into play. OneM2M functions as a software middle layer, by interconnecting devices with their respective application-infrastructure entities (cloud-based), independently from their underlying transport networks. In effect, it creates an abstraction layer that allows application developers to create value from their business and operational applications without having to deal with the technical protocols for connecting to and managing devices.

OneM2M solves the problem of implementation variances for common service functions. Its technical specifications provide a global standard for the basic functions, such as device management, security, registration and so forth, that all IoT use cases employ. The use of oneM2M specifications in field-deployed devices ensures data and vendor interoperability.

Furthermore, oneM2M provides global standardized APIs on the application-infrastructure side, where customers can interact with their device and/or even their own platform. On the device side, oneM2M’s APIs help developers tailor applications for their specific purpose without the need to master technical details about the underlying connectivity networks.

To enable end-to-end communication across different verticals, oneM2M provides the tools that enable various interworking possibilities. One approach is to map data models for shop-floor machines and sensors as oneM2M resource structures and vice versa. Since such interworking definitions are available for other verticals, such as automotive and rail, different verticals can communicate among each other relatively easily.

Working across the IoT ecosystem

The primary aim of oneM2M is to standardize the common services necessary to deploy and operationally support IoT applications across multiple verticals. This implies a horizontal focus, aiming for a high degree of reuse and cross-silo interoperability. Vertical sector requirements are also important to oneM2M standardization participants. In the manufacturing and industrial sectors, oneM2M established a liaison with the Industrial Internet Consortium. In Europe, oneM2M is working with Industrie 4.0 members, beginning with a workshop on February 12, 2019.

OneM2M is also actively involved with the Open Connectivity Foundation, targeting interworking opportunities for consumer IoT applications.

OneM2M’s own standardization continues to address new frontiers for interoperability and interworking with the development of its latest specifications, Release 4. Release 4 will encompass industrial, vehicular and fog/edge architectures. It also lays the groundwork for semantic interoperability and tools to help user adoption.

All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.