Software installation on a remote device is critical for any business dealing with operations at a massive scale. No software stays the same. Instead, it goes through several iterations of improvement wherein bugs are fixed/patched, or new features are added; this requires a new version to be released.
Software management for IoT devices is as important as device management is. Software management comprises publishing, distributing, and managing over-the-air (OTA) updates for everything from tiny sensors to gateway-level devices. It is practically impossible to update the device software by visiting each device in the field. The Azure IoT hub gives us many options to push these updates remotely and wirelessly, known as OTA updates. One can also leverage the basic features of device-cloud communication to deliver OTA updates in a customized manner.
The device life cycle (management?) is one such feature that can be combined with Azure Function to do the OTA for the first time. Device lifecycle events allow cloud applications to be notified in real-time of device identities being created or deleted in the IoT hub. This helps the developer in designing device provisioning and de-provisioning business logic. To generate this logic, the IoT hub needs to create a route, having the Data Source equal to “Device Lifecycle Events,” and the endpoint should be a built-in Event hub of IoT hub. Let’s see how it can be utilized.
The Azure IoT hub documentation recommends using device twin properties to send the device firmware update. The cloud application has the UI to pick the appropriate software, and its firmware URL and version are set to twin the desired properties of the device. The device twin properties are JSON documents that store device state information, including metadata, configurations, and conditions. The cloud application sets the desired properties, and the device program reads them. This works fine when the software updates are not extensive in terms of manifest content size.
Typically, the device requires the location or URL of the software binary & its new version, but sometimes the device may need additional details. For example, a software signature could be part of the OTA update. The software signature ensures the integrity of firmware and software running on a device. It also guards against malicious firmware, rootkits, and unauthorized software updates that could happen during device reboot or OS re-launching, or some additional tokens may be needed for downloading the binary from an authenticated source.
Sometimes, there could be multiple software required at the time of the first software installation. In such cases, device twins could be limited in terms of size. The maximum size of twin desired properties is 32 KB. Hence, there would be a need to find other alternatives.
Apart from twin properties, cloud-to-device (C2D) & device-to-cloud (D2C) are other ways to establish communication between the device and the cloud. The primary difference between these and twin properties is the maximum size of the message. C2D messaging can send a message with a maximum size of 64 KB, double what twin properties support, and thus, C2D messaging supports large content.
Now let us understand the second part, which is the device lifecycle event. The Azure IoT hub sends a message via the event hub whenever any new device is registered in the IoT hub, or an existing device is deleted. For instance, when createDeviceIdentity event is raised, the following message is generated.
The message properties contain the IoT hub name, device ID, the timestamp when the device was created, the message payload schema, and operation type of device lifecycle event. The message payload contains details related to the device such as device ID, device twin properties, etag, and deviceScope. When performing the OTA updates, the device ID is enough to pick the relevant software from the back-end application, and created device event serves that purpose.
The third component in this design is Azure Function. The Azure function listens to the event hub of the IoT hub. It receives the device lifecycle event message and calls the device manager API to send the OTA manifest by fetching the relevant software for the device. The OTA manifest is simply a JSON containing the data required to execute the software download, verification, and process invocation. The diagram given below shows how the flow works in sequence.
Let us understand how the flow works. First, the device is created using the device manager API or the UI app that consumes those APIs. It is assumed that while creating the device, the relevant software is associated with it.
After creating the device, it’s also registered in the Azure IoT hub. After successful registration, the createDeviceIdentity event is triggered, and the Azure function listens to the event hub of the IoT hub to capture the event.
After receiving the trigger, it invokes the device manager API to send the C2D message with the initial OTA manifest. The device manager API prepares the OTA manifest by finding the relevant software associated with the created device using the device ID. Once the C2D message is sent to the device, the role of the cloud side is done.
On the device side, the device host program should have the C2D message handler. Based on the received message, it should take some action. The OTA manifest schema is shared with the team working on the device host program to understand the message and process the OTA update. The typical OTA update process involves the downloading of binary files. After downloading, they should be validated against the software signature to avoid the installation of malformed software. Then the process for that software is initiated.
Once the process begins, the device can perform the operations leveraging that software. The device sends the OTA feedback for each OTA sub-process like downloading, validating, and running of software. The OTA feedback is sent via D2C messaging. The same Azure function can be used to receive the OTA feedback messages and forward them to the device manager via an API. The OTA feedback helps in tracking the overall OTA process status.
This approach gives us more control over the OTA manifest schema and OTA feedback mechanism Compare to using Device Twin flow for OTA operations. Also, the large size of the C2D message enables the sending of more metadata while doing OTA operations. The initial OTA update is critical whenever the device is provisioned in the field, and these devices can be utilized as soon as the update is completed.
eInfochips provides a range of services to build a complete IoT platform consisting of IoT cloud back-end APIs, device firmware, state-of-the-art UI application to manage IoT devices and mobile applications. We are proficient in developing turnkey IoT solutions with enterprise-grade security, scalability, reliability, and productivity on well-known cloud providers i.e., Microsoft Azure, Amazon Web Service & Google Cloud. To transform your business with IoT digitization and digitalization, say hello to us.
