By: Ken Figueredo, Joachim Koss

When attending a cocktail party or similar social event, a person can expect to meet old friends. They might also make completely new acquaintances via friends of friends or the host’s introductions. Some of these new acquaintances might be people from out of town. Others might speak in a different language, requiring a translator or third language for communication. 

There is no reason why this human-centered scenario should not apply to connected devices, sensors and IoT applications. In the case of consumer IoT components, the equivalent of the party gathering might be a home. Other environments might be office buildings, cities, factories, and even transportation networks. In each of these places, the growing proliferation of IoT applications and devices creates new opportunities for cross-silo applications. Like the party host, there is also the potential to economize on hardware and communications costs by using one IoT sensor to serve data to multiple applications.

Two factors are involved in enabling ‘conversations’ between IoT devices and applications. The first is a common framework that allows different IoT devices and applications to communicate with one another. This is generally one of the functions of an IoT platform. The second requirement is a shared set of rules that allows devices, sensors, and applications to exchange IoT data. This comes under the discipline of semantic interoperability.

Interoperable framework for IoT platforms

In 2012, a group of leading standardization bodies launched the oneM2M initiative to establish a standard for end-to-end and interoperable IoT systems. These bodies wanted to avoid regional fragmentation and promote a global IoT market, reflecting the foundations and successes of the mobile telecommunications industry.

The oneM2M standard addresses situations where an organization can deploy an IoT solution, using components from different suppliers, and then add other solutions over time. The use of an IoT middleware capability between sources and consumers of IoT data aims to mask complexities along the IoT technology stack. In effect, the oneM2M standard defines a three-layer, horizontal architecture that is reusable across different application sectors. The lower layer corresponds to devices and communications technologies. The upper layer corresponds to applications that process data from IoT devices and sensors for decision-making and control interventions. oneM2M’s technical specifications define a set of common service elements that reside in the middleware layer.

One way to think about these common services is as a set of technical capabilities that application developers can use to design and deploy IoT systems. Many of these are common to all IoT applications. Take the example of the ‘registration’ service. A developer could use this to establish the authorization and authentication relationships between different device, gateway, platform, and application entities in an IoT system.

Another common service function is security. Here, oneM2M defines a common approach for the handling of sensitive data, security administration, establishment of security associations, access control (identification, authentication, and authorization) and identity management. One of the benefits of oneM2M’s approach is that developers can use and reuse the set of common services to build applications for public safety, smart cities, intelligent transport, and other sectors. In addition, oneM2M’s standardization framework allows new common services to be added to the toolkit as new requirements emerge over time.

Enhancing IoT systems for semantic interoperability

Having overcome issues of basic connectivity and network interoperability through the horizontal architecture and common services, syntactic interoperability becomes the next challenge. This relies on the use of information models to represent IoT devices, using static information based on a pre-defined syntax. In the case of a heat sensor, for example, the pre-defined syntax might specify that data is sent as a floating point, temperature reading.

Once requirements about information exchanges becomes more complex, as is the case with systems from different domains, static information is no longer sufficient. Now, there is a need to base the exchange of information on its meaning, independent of underlying protocols. Returning to the heat sensor example, semantic attributes might indicate that the reading comes from an indoor sensor that is situated on the second floor in a specified commercial building.

The next complication arises when data sources and data-requesting entities use different ontologies because they are developed by different companies not using a common ontology. When devices or a service application want to read and understand data, semantic interoperability is needed. It combines the ability to establish a shared meaning of the data exchanged as well as the technologies to interpret communication interfaces.