Introduction: A new engineering challenge posed by IOT is seamless interoperability with the very large volumes are volumes of things. A single IOT deployment may have tens of thousands of things in it. To make this feasible, we need systems were we just drop the thing in and it works, including things made by third parties.
Interoperability is often considered only at the communication level or at the cloud level in terms of cloud APIs. However, interoperability can also be considered at three different levels:
- Device level – how can Things be wired to other things, so that they can interact? What interface should the device present?
- Intranet level – how a Thing be networked with other things, so that they can interact autonomously of the Cloud? If the internet connection goes down they still need to work.
- Internet level – What comms/transport should be used? What does the application payload API look like?
Key engineering challenges: The main engineering challenges in IOT interoperability relate to the design of data models, Applications Programming Interfaces (API) and building modularity into an IOT design.
Data models underpinning the IOT need to a strong object-oriented structure in the way things are conceptualised and they need to be standardized. The data model should cover the methods and functions that operate on that data and how that's distributed around. Key questions include: What of that data model resides in the thing? What of it resides in network control? What of it resides in the cloud?
The interoperability at all levels is enabled by the Applications Programming Interfaces (API) and the bridging between the APIs. Many IOT designs don't have the concept of an API, i.e. a clean interface. When there has been some thought put into APIs in IOT, it usually means there's similar concepts that can be bound together, configuration-wise, without software. Although, sometimes you will need to write some software to actually bind the two together.
APIs are needed at multiple levels including in transport, bridging, translation and routing. Each of those present huge challenges. Translation is needed when you're connecting things and is simpler when well thought out Applications Programming Interfaces (API) are present, even when they do not perfectly align. An example of the challenges in routing is around how to allocate IPv6 addresses and how that maps to the configuration of an Intranets of Things within the wider Internet of Things.
The sheer complexity of thing-to-thing relationships in large deployments is challenging. For large scale deployments, it is unrealistic to be writing thousands of different bits of code. A key to interoperability in IOT it to adopt a mindset of modularity. The more modular your IOT system the more likely those things are to be interoperable.
One approach here is to think in terms of application language and transport language as separate things. Application language is the logical operational user-oriented language. Transport language comprises just the communications channels. In a big IOT system, the transport is just the infrastructure. The application just sits over the top of the transport to actually implement what you want to do. The application is transport agnostic, so if one is able to model and define your application language as separate from your transport language, you're going to end up with a really modular, highly deployable system across various different transport layers.
Relevant standards and regulations:
Sources: Material on this page has primarily been sourced from the following:
Presentation by Jon Eggins, Chief Operations Officer, Genesys Electronics Design; Systems Architect, Genesys Products titled Thing One and Thing Two – Myths, Philosophy and Engineering
Edited by Tim Kannegieter