This is a follow-up part of the article on the topic of remote management of IoT devices. First part is available here: Remote management of IoT devices.
In the first part, we introduced several kinds of remote management and its examples. We argued that each kind has its specific purpose and place within an IoT solution.
However, selecting a suitable kind of cloud-to-device communication is the first step toward a reliable production-grade IoT solution. Now, we need also to make sure that:
In this follow-up part, we will look into these challenges in more depth, and discuss how they can be overcome and how IoT platform products can help.
Contents of this part of the article are:
Successful IoT solutions typically face the following two challenges:
From a certain point, it is not feasible to deal with these challenges using cloud-to-device communication on a per-device basis (e.g., updating device twin for each individual device). Although some scripting skills of the solution operators might help, inherently tricky technical problems need to be approached more scalable way.
The scalability challenges will be demonstrated in a simple case of applying the same device twin update to many devices. Let’s assume a fleet of devices that have device twins that look similar to this:
There is maxSpeed property for which an operator can set the value via desired property, and the device can report actual maxSpeed via the reported property. More on this example can be found in the previous part of the article: Remote management of IoT devices.
In this example, let’s also assume that there are multiple versions of the device, and the specific version can be inferred from the device ID (the device ID is structured like this: device-xyz-v3.1).
Now the device operator is tasked with setting the maxSpeed property for all devices of version v3.1.
A naive approach to this task could be to first list all devices, select the relevant ones based on version and then update the device twin for each device individually.
Using this naive per device, the operator must send a request to the relevant cloud API for each item in the resulting list of devices.
With some basic scripting skills, these tasks might be simple for smaller IoT solutions. However, with the growing number of devices, several issues arise:
Such reliability calculation is wildly theoretical, and the real numerical representation of reliability can differ. However, the exponential relationship between reliability and the number of devices is the hard truth we must deal with.
Both execution time and reliability of the scripts can be improved by using parallelization techniques (sending multiple requests at once) and implementing retry policies (detecting and retrying failed requests with reasonable delays). However, with these improvements, the complexity and requirements of the scripting tools and developers skyrockets.
To deal with the challenge in a scalable, reliable, and correct way, an existing solution in the form IoT platform can be used. The such platform should provide a simple way that allows operators to define not just a single target device but multiple devices at once. Also, the way of defining multiple target devices should be more intelligent than providing just a list (otherwise, we would still face the issue with accuracy/correctness).
The way to go here is for the IoT platform to accept configuration along the following lines:
where the operator defines that the desired device twin property speed should be set on all devices whose names start with the string ' model-v3.1'. This configuration is persistently stored in the IoT platform and continuously evaluated.
This approach has the following benefits:
For more mature IoT solutions, there is typically also a need for multiple such configurations (e.g., for multiple device models and/or features). In such cases, it is essential that the IoT platform provides a deterministic and transparent way of applying multiple configurations to a single device and dealing with conflicts.
The challenges and solutions to scaling cloud-to-device messaging and remote procedure calls (RPC) are similar for device twins:
However, in practice, the need for sending the same message and/or RPC to many devices is much smaller than for device twins. In particular, for RPCs, it is very rare to have a use case requiring calling multiple devices simultaneously. Also, given the synchronous nature of RPCs and the exponential relationship between reliability and the number of devices, it becomes infeasible to call many nature of RPCs and the exponential relationship between reliability and the number of devices, it becomes infeasible to call many devices at once and expect all calls to succeed, especially considering that some of the devices might not be connected or have a poor connection at the time of the call.
IoT platforms are here to facilitate all kinds of cloud-to-device communication reliably. This applies to small solutions that communicate with each device individually and to large solutions that face scaling challenges.
IoT platform should provide a rich set of interfaces for cloud-to-device communication that can support all typical roles/users of an IoT solution:
Suitable graphical and command-line interfaces should significantly save time and be safe (designed in a robust, non-error-prone way so that users are less likely to execute destructive actions unintentionally).
APIs (Application Programming Interface) and SDKs (Software Development Kits) are crucial for extensibility. Especially in the case of cloud-to-device communication, the IoT platforms that do not provide a high-quality API cannot be easily extended with custom business use cases, thus significantly decreasing the value they can bring.
Let’s assume a fictional company X that manufactures and sells sophisticated industrial devices/robots of arbitrary kind (it could be, for example, an electron microscope, milking robot, or harvester), and the following requirements apply:
Company X needs to build a software system to support this scenario. How do we approach such a situation? Here is where an IoT platform comes into play.
Let’s put aside topics related to connecting devices to the platform and focus on the matter at hand - cloud-to-device communication:
1. Assuming that the device is technically able to execute its software/firmware update, the IoT platform can provide tools for administrators to trigger or otherwise control the update procedure (e.g., via Device Twins).
2. Enabling optional features could also be implemented via Device Twins. However, in this case, we do not want to update all devices simultaneously. Instead, we want the support staff/device operators to update only specific devices when an end customer purchases the extra feature.
3. The custom web application will be implemented by company X’s software department. With a proper IoT platform, company X’s software engineers can simply use the platform’s API or SDK, do not have to deal with all the challenges discussed in this article, and focus on the added value of the end-customer application instead.
In this second part of the article, we discussed challenges that surface when cloud-to-device communication is applied at scale:
The security of IoT devices is complex and has many facets. While there are various types of IoT devices available, there are some fundamental security aspects that every IoT solution designer should bear in mind. To learn more about IoT device security, check out our concise guide.
Integrating devices with IIoT platforms can be easy. We will outline what tools the platforms offer to integrate devices and explain a secure and scalable approach to device provisioning and integration.
In this article, you will learn about IoT cloud-to-device communication and its several kinds, including examples. We explain that each kind has its specific purpose and place within an IoT solution. Selecting a suitable kind of cloud-to-device communication is the first step toward a reliable production-grade IoT solution.