IoT Reference Design Framework

The IoT industry seems deeply preoccupied over ideas for IoT reference architectures, cloud-based platforms and edge computing technologies. However, before solution designers leap to the latest flavor of technology, it is worth stepping back to reflect on the characteristics of an IoT application or, more realistically, a group of interoperable applications and then to translate these into a set of logical requirements.

The next step is to map these logical requirements into a physical architecture, which entails a process of design, performance and cost trade-offs, to select suitable technical solutions. This approach avoids the pitfalls of working back from any given technology and positing it as the solution to all IoT problems.

To understand this process, let us begin by defining a straightforward application, which consists of a combination of sensors, and connected devices that communicate with an application. This arrangement relies on intermediary communications networks. It also depends on a suite of IoT service-enablement functions, such as device-management, which require an IoT platform. In industry parlance, this describes an OT (operational technology) solution.

IoT applications in the OT domain generate a considerable amount of data, which is useful in enterprise management systems. A fleet management solution for delivery vehicles, for example, can keep track of vehicle location information. By linking this (OT) application to an enterprise’s IT system, it is now possible to target supply-chain efficiencies and to enhance inventory management. This is an example of OT/IT integration, which is emerging as an important issue in the industrial IoT.

Real-life applications are more complex, especially where enterprises have to accommodate legacy systems and interactions with business partners. Therefore, it is useful to characterize an IoT-enabled solution in relation to OT, IT and commercialization building blocks.

The OT domain may involve standards-based and proprietary data sources from a variety of connected devices, sensors and data feeds. Data sources may take the form of third party financial, traffic or weather feeds, for example. They could also be less dynamically changing data sets maintained in Excel.

 In complex environments such as factories, offices and transport hubs, there could be multiple groups of sensors, each overseen by its own device management platforms, for example. An organization’s OT domain could conceivably include multiple IoT applications and multiple IoT service-enabler platforms.

There are advantages to consolidating different device, sensor and data feeds into a common environment for two reasons in particular. One is to facilitate interoperability between silo-like, IoT applications; this could be a factory assembly cell interoperating with an application handling a continuous production line in a related part of a factory. The second is to make OT domain data easily accessible to IT domain applications (via a common interface rather than multiple point-to-point integrations).

In terms of a physical architecture, this is where decisions arise about cloud vs. edge computing preferences. This is also the point at which designers have to select suitable methods of integration (e.g. point-to-point APIs, common data bus, data exchanges etc.).

Within the IT domain, solution designers have to deal with families of commercial off-the-shelf software packages and custom-built applications. How should these interact with components in the OT domain and where should computation and decision-making be concentrated? Answers to these questions determine what types of connectivity, platform and edge computing technologies are appropriate.

An important complement to the IT/OT envelope relates to commercialization functions. This could take the form of new pricing schemes and revenue sharing models involving different partners in an IoT application. Sometimes these functions are addressed in the OT domain, via IoT service-enabler platforms. Sometimes these platforms lack the flexibility to support complex pricing schemes so implementation has to occur through a commercialization domain capability.

 As IoT ecosystems grow, individual companies will benefit from partner management tools (e.g. onboarding of a new supplier, standardizing commercial terms and service level agreements etc.). The requirements associated with commercialization lend themselves to the platform business-models of Amazon and Uber, which expose core assets to encourage complementary, third-party applications.

This IoT design framework helps service providers (i.e. users of IoT applications) and technology suppliers to define the end-to-end requirements of an IoT service (i.e. an IoT application and its associated service delivery business model). It helps to define which functional areas they address and to choose appropriate technology solutions.

It also offers a systematic way to think about over-arching system requirements such as policy rules (e.g. access control, authorization) and security, both of which span different logical building blocks of an overall IoT solution.