By Matt Hatton, Founding Partner, Transforma Insights.
Transforma Insights published a Position Paper in July 2023 entitled ‘Connected-by-Design: Optimising Device-to-Cloud Connectivity’. The report examines the ways in which the IoT solution development process requires a new approach whereby considerations of connectivity permeate the whole design process.
In this article we consider one aspect of the topic: the complexity involved in building IoT solutions and why connectivity is the glue that binds it together.
If we think of the entirety of an Internet of Things use case, the ‘full stack’ that might need to be considered by a developer, it is complex, comprising eight principal layers: sensors and actuators, operating systems and containers, compute and storage, applications and data, business and process integration, security, management, and connectivity. Each needs careful consideration.
Devices: compute at the edge
The sensors and actuators are where the ‘rubber hits the road’ in terms of IoT’s prime activity: acting as the interface between the physical and digital worlds. Sensors are almost inevitably part of a device, which incorporates all of the various other hardware elements, including power, processor, memory and connectivity module. And the devices will include some element of software/compute. One aspect is the embedded operating system (OS), where there is a range of approaches. In some cases devices will rely on a full OS such as Linux or Windows to support an IoT device, although this approach is inherently inefficient because it supports features that will not be needed. As an alternative there is a set of constrained embedded operating systems for IoT, including Amazon’s FreeRTOS, RIOT, TinyOS and Zephyr. The availability of such OSs with minimal requirements for processing and memory supports the reduction in hardware prices for memory and processing components.
The other aspect of the IoT device is edge compute. This needs to be considered in the context of the wider compute/storage architecture of the IoT use case. The increasing prevalence of cloud computing, including in the context of how IoT is deployed, has been well documented. A large proportion of IoT applications are hosted in the cloud, and take advantage of increasingly sophisticated and flexible capabilities, including specialised and powerful compute resources, such as GPU and FPGA for handling richer media transcoding, analytics and AI/ML, as well as distributed architecture incorporating approaches such as containers, Kubernetes and serverless computing. Alongside this we see the increasing importance of edge computing. For IoT applications, which are inherently decentralised, the idea of placing increasing intelligence on the device or more proximate in some way to it (e.g. at a campus edge or network edge) is logical. This is inherently more efficient, reduces the load on network resources, and reduces the response time.
An increasingly critical role will be to manage the relationship between all of these complex, specialised, distributed and powerful compute resources, in a way that optimises the application. The ability to orchestrate where IoT data storage and processing is occurring, as well as efficiently deliver data between device, edge and cloud, is a clear requirement for future IoT.
Application data and end-to-end security/management
The next element of the IoT stack is the application/data, which will be highly specific to the use case in which the deployment occurs. The critical thing is that choices made about application logic will have significant implications for other aspects of the deployment, and vice versa. Deployments in highly constrained environments (e.g. high latency, low bandwidth, poor coverage or limited power) will need to be architected in a way that is appropriate for those constraints, whereas those being deployed free from such constraints would work very differently. Additional to the application data, there is also the requirement to integrate to back-office CRM and ERP systems.
There are two further ‘layers’ which in reality are relevant across the whole of the stack. Security should not be considered as a layer in its own right, but as permeating all of the other layers. For instance, in hardening the device to prevent tampering, network layer features (includes SIM authentication, private APNs, and network diagnostics and troubleshooting), Transport Layer security (including PKI, TLS and IPSec VPN), cloud storage (e.g. data storage and securing interfaces), and the application layer, which is usually the most insecure, due to it being most exposed to end users. There is also a strong requirement for end-to-end security, integrating all of the previously mentioned layers, based on ‘secure-by-design’ principles. The other full stack element is management. The enterprise needs to have full transparency and management control over all aspects of the IoT deployment, incorporating device management, connectivity management, and data management.
Connectivity: the most critical layer
The one layer that has not yet been discussed is connectivity (or networking). This provides the mechanism for delivering data between the other elements of the stack. As such it is the most critical consideration when architecting an IoT deployment. It will typically be the element over which the developer has least control, in terms of which options might be available, and therefore needs to be prominent in a developer’s consideration. Because of the inherently distributed nature of IoT, the number one priority for any full stack IoT development is to ensure that the connectivity ‘glue’ is done correctly. While every use case’s application, data, operating system, compute, storage and power constraints deviate significantly, perhaps the most dramatic variability can be found in their connectivity – the very thing that classifies the device as an “Internet” of Things device.
The need to be ‘Connected-by-Design’
Because of the criticality of connectivity as part of the IoT full stack, Transforma Insights believes that it is critical that considerations of connectivity permeate the entire development process. In the same way the ‘secure by design’ principles require that developers consider security throughout the development process, rather than overlaying after the event, so too should considerations of connectivity. Choices about connectivity technology, protocols and architecture will have enormous implications for other elements of the stack, meaning that connectivity can not simply be bolted on at the end as an afterthought. IoT developers also need to adopt an approach of ‘Connected-by-Design’, whereby decisions about connectivity technology permeate the whole development process.