Image from Iconfinder
Internet of Things (IoT) middleware is system software, which typically facilitates secure, scalable, reliable and high-performance access to data and services of Internet connected objects (“things”). As such, it is an integral element of any non-trivial IoT deployment.
Since the very early days of IoT, the primary functionalities of IoT middleware were focused on providing connectivity between “things”, while making their data and services accessible to other IT systems and devices. To this end, middleware functions were mediating between data providers and data consumers in order to ensure reliable and/or high-performance connectivity between them. Furthermore, as IoT systems grew in complexity, dynamic discovery functions were added, in order to enable applications to select the IoT resources that they would like to use based on criteria such as their functionality, type and location.
Despite the evolution of IoT middleware platforms and their expansion with a great number of additional features (e.g. Cloud integration, device management, scalable data analytics), connectivity functionalities remain at the heart of IoT middleware platforms. The reason for this is that connectivity is always a prerequisite for exchanging data between the various actors (i.e. people, IT systems, IoT devices) of an IoT deployment. Moreover, connectivity enables data exchange across all layers of an IoT application (e.g., device, edge node, Cloud), across different vertical functionalities, as well as across different functional domains (e.g., devices control, IoT applications, knowledge extraction from IoT data, integration with enterprise systems).
Therefore, the vast majority of modern IoT platforms (including IoT/cloud platforms provided by major vendors such as for example Microsoft[1], IBM[2], SAP[3] and Amazon[4]) offer middleware libraries for things connectivity. These libraries abstract the implementation of connectivity functions and prove high-level Application Programming Interfaces (APIs) for accessing data stemming from “things, as a means of reducing development costs, increasing productivity and facilitating high-quality implementations.
Core Connectivity Functionalities
Despite variations in the connectivity functionalities, most platforms provide support for the following functionalities:
- Identification, naming and addressing: In order to access the different “things” and IoT resources there is a need for uniquely identifying them. To this end, an identification mechanism is needed, along with accompanying naming and addressing schemes, which map a thing’s identifier to a name and a network address respectively.
- Modelling IoT resources: All data that originate from the “things” (e.g., machines or devices deployed in a plantfloor) refer to some real-world entities such as physical devices and processes. The connectivity middleware provides a digital representation of the “things”, which models the instances of the available field devices and keeps track of their state. The latter is likely to change dynamically as a result of changes in the physical world. Overall, an IoT connectivity middleware platform comprises a digital model for machines, sensors, robots, devices and other entities of the physical world. Note that the information kept within a data model, includes the identifiers of the things, as well as the types of data exchanged between them.
- Lifecycle management: Along with the digital modelling of the things, an IoT connectivity middleware platform provides functions for managing the lifecycle of IoT entities. While the above-listed model represents the various entities and their instances, the lifecycle management functionalities provides the means for creating, updating, deleting and reading the instances of the entities. An instance will be created when a new thing appears in the field, while it will be deleted when it will leave the field. Moreover, information about a thing will be updated whenever the state of a field device changes.
- State management: Several physical objects (e.g., smart sensors, industrial robots, cyber-physical systems) transcend different states during their engagement in an IoT application. The state management functionality ensures the tracking and storing of their states (including full history of state changes) in order to facilitate the synchronization of the physical object with its digital representation in the IoT system. State management functionalities are essential for IoT applications with decentralized logic, notably application with smart objects that feature embedded intelligence. The latter operate in an autonomous fashion and synchronize themselves with the middleware when connected to the IoT platform.
- Publish-Subscribe: The publish-subscribe pattern (push mode) provides a means for exchanging data between two systems or things. According to this pattern, an IoT component publishes data on a given topic, which is then received by other IoT components that have subscribed to this topic. Publish-subscribe enables decouples publishers from subscribers and implements asynchronous communications between them. It is a proven pattern, which ensures reliability, scalability and high performance in the communication of distributed IoT systems and devices.
- Request-Reply: This is a data exchange pattern (pull mode), which is based on an initiation of a request for accessing the data or services of an IoT component. Accordingly the request is fulfilled by the IoT component in either a synchronous or asynchronous fashion. In the synchronous case, the requester waits for the request to be fulfilled. On the contrary, in the asynchronous case the requester can generated many requests for IoT data and services prior to having its previous ones fulfilled.
- Discovery: This provides the means for discovering IoT resources (i.e. components, messages and message topics) in order to increase the automation and dynamicity of the IoT application.
- Quality of Service (QoS): This functionality ensures the quality of the delivered data through appropriately configuring parameters of the middleware such as whether message should be delivered in a reliable or best-effort way, but also whether messages should be cached.
- Security: This building block ensures the confidentiality and integrity of message exchanges between IoT components, while at the same provide the necessary authentication and authorization features.
All the above functionalities are accessible to developers of IoT systems based on APIs. Such APIs are provided in different languages, depending on the languages support by each platform (e.g., C/C++, C#, Java, Javacript, Python). Language specific APIs transform the above listed abstractions to concrete implementations that empower IoT applications.
Industrial Internet Consortium’s Connectivity Framework and Related Connectivity Technologies
The above listed functionalities and building blocks are in general part of most IoT middleware implementations, yet they have been prescribed in an abstract way rather than in the context of a specific platform. Most of them are specified in detail as part of Industrial Internet Consortium’s Connectivity Framework (IICF), which has been recently released[5]. IICF is the connectivity framework that empowers the implementation of the Industrial Internet Consortium Reference Architecture, which specifies a full stack of functionalities comprising IoT systems.
In addition to specifying a set of abstract connectivity functionalities, the IICF presents some concrete connectivity technologies, which provide support for the identified functionalities. These offer different advantages and disadvantages in terms of their performance, interoperability, quality of service and other characteristics. These technologies include the DDS (Data Distribution Service) specified by the Object Management Group (OMG)[6], the OPC-UA (Unified Architecture) communication standard by the OPC Foundation[7], the oneM2M partnership project[8], the Constrained Application Protocol (CoAP) specified by the Internet Engineering Task Force (IETF)[9], as well as the MQTT[10] (formerly Message Queuing Telemetry Transport) by the Open Artwork System Interchange Standard (OASIS)[11]. As evident from the listed standards, a wide array of connectivity technologies have been introduced by different standardization bodies, serving different purposes and business requirements.
While a detailed presentation of each one of them is beyond the purpose of this article, we strongly believe that IoT developers and solution providers explore them thoroughly prior to selecting the most appropriate connectivity technology for their application. Indeed, while all these standards provide the baseline connectivity functionality, we all know that the devil is always in the detail.
[1] https://www.microsoft.com/en-us/internet-of-things/azure-iot-suite
[2] https://www.ibm.com/internet-of-things/
[3] https://www.sap.com/product/technology-platform/iot-platform-cloud.html
[4] https://aws.amazon.com/iot
[5] https://www.iiconsortium.org/IICF.htm
[6] http://portals.omg.org/dds/
[7] https://opcfoundation.org/
[8] http://www.oneM2M.org
[9] http://coap.technology/
[10] http://www.mqtt.org
[11] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt
All information/views/opinions expressed in this article are that of the author. This Website may or may not agree with the same.