Many Internet of Things (IoT) systems tackle a single problem, focusing on issues that are particular to any industry vertical. General-purpose solutions are unusual. One reason for this is because organizations are under pressure to show quick results. As a result, developers find it easier to adapt an existing system.
The most straightforward approach begins with the addition of connectivity to a sensor or machine to enable remote access and data gathering. The next step is to connect to a cloud-based data management system for analytics and visualization purposes. This design approach does not help in anticipating how such a system might evolve or how it might be supported over its life cycle. Nor does it encourage a strategy of reusing design tools and technology components as other applications are developed.
Are All IoT Systems Unique?
If an organization plans to deploy multiple IoT systems, are there commonalities, or is each application unique? Commonalities mean that there is scope to reuse design patterns, architectures, and standards.
The composition of a simple IoT system has four components. These include the connected sensor or device; a communications network for remote connectivity; a platform for housekeeping tasks such as device management, security, and registration; and an application or visualization dashboard that uses the IoT data from the connected sensor or device.
More complicated arrangements might involve an intermediate gateway or communications between multiple silo applications. There may be a mix of components from an implementation standpoint from different suppliers, some using open standards and others combining open-standard and proprietary technologies.
One approach to overcome the uniqueness of IoT systems as they evolve or become more complex is to treat them as ‘any to any’ systems. In other words, any IoT application or dashboard should be capable of ingesting data from any connected device or sensor. It should also be possible to substitute any device or gateway supplied by one vendor with equipment supplied by another. Viewed through this perspective, the challenge of building IoT systems becomes less of a vertical technology stack issue and more of a horizontal architecture one. By reframing the challenge, it now becomes possible to reuse design approaches and developer tools.
Strategies for Reuse
The most straightforward approach to supporting IoT systems in multiple application domains is to take a tried and tested system and generalize it to other domains. Many hundreds of IoT platforms exist in the marketplace, and many are pursuing this kind of bottom-up approach.
A second approach is to analyze a range of IoT architectures and frameworks and identify areas of overlap which represent opportunities to enable interoperability. Research initiated by the US National Institute of Standards and Technology (NIST) follows this approach in the form of common, Pivotal Points of Interoperability (PPI). Further work by Open and Agile Smart Cities (OASC) members extended this concept to define Minimum Interoperability Mechanisms (MIMs). One motivation for these approaches is to accommodate legacy systems and standards. This results in a focus on systems interfaces to solve the interoperability challenge.
A third and more generalist approach begins with an analysis of multiple use cases across different verticals. The goal is to identify architectural and functional commonalities across use cases. Examples of common functions in all IoT systems include communications management, device management, and security. These are examples of horizontal middleware capabilities that facilitate interoperability between IoT applications and connected devices and sensors.
A Toolkit Approach for Common Service Functions
Relatively few tools are required to build basic IoT systems. A starting point is a ‘Registration’ function to establish authorization and authentication relationships between an IoT platform and connected device or application endpoints. Next, a ‘Communications Management’ function handles the transfer of data between system components, determining when to use which communication channel and to buffer communication requests for later transmission when needed. A ‘Device Management’ function commonly exposes devices and gateway capabilities towards IoT applications.
Over time, the IoT system can be enhanced with new tools. A ‘Semantic Interoperability’ tool, for example, would support abstract data modeling and the application of semantic descriptions to enable the exchange of data between different entities and sub-systems. With growing interest in data monetization, a ‘Service Charging & Accounting’ function would manage charging policies and generate charging records for data communication events and the consumption of data storage resources.
IoT platforms provide a framework for these kinds of IoT developer tools. Since each platform follows its own approach, developers need to master the specificities of more than one platform because common functions are most likely defined in different ways. This hampers interoperability between applications on different IoT platforms because developers are using different tools. Standardization circumvents this problem. This shows up in the growing adoption of the LWM2M standard for device management. It is also why organizations use CoAP and MQTT standards for communications management with constrained devices.
https://www.iotforall.com/building-iot-systems-with-reusable-tools
