Software update is one of the major parts of the modern big IoT Solutions. This is probably also one of the most critical and sensitive parts in IoT Solutions. In a series of articles I will try to explain the major approaches i design and implementation of software update for IoT devices.
The first article is focused mostly on the major cases in software update in general and in Azure IoT Solutions particularly.
Why we need software updates for IoT devices?
Modern IoT Devices can be very different: from very simple embedded devices to very powerful boards, based on different architecture.
Software for IoT devices can be considered in several groups:
- Device Firmware (that provides the low-level control for the device’s specific hardware)
Application Software in 2 groups:
- Software packages (groups of files and information about the software)
- Visualized applications (contains groups of containers)
Nowadays it is realistic to have not only back-end services, implemented as containers, but also to have containers, running on the devices.
Containers are well-positioned to address some of the main challenges that developers face when deploying software to IoT devices:
- Minimal hardware resources
- Widely varying device environments
- Limited network access (containers, especially Docker allow incremental updates)
Main components of software update for IoT devices:
Modern IoT devices software update systems have several components, which can be considered on the conceptual level, agnostic to the type of the software
- Metadata in IoT Device Management System DB
- Software to manage downloads, installed on IoT Devices
- Secure communication, used to download packages
- Synchronization between devices and back-end about upcoming updates.
- Software Bundling (grouping the updated in “bundles”)
- Campaign Management (managing updates by pool of devices, to be possible to manage the workload when process the software update)
Repository for software update can we different:
from Debian package repository like APTLY , multi-package repositories like JFrog Artifactory or repository for containers like Docker Registry . Quite popular are container registries, implemented as SaaS for different cloud providers like Azure Container Registry.
2. Metadata on software packages (containers)
Metadata can be stored in several places:
- Repository integrated metadata
- Packages/ containers metadata
- Metadata, persisted in database (usually part of IoT device management system)
3. Software to manage updates:
it could be various: from extended standard Linux commands like apt-get to specific applications to manage the whole download process.
Below are listed several most used options:
- Embedded OS tools
- General systems for upload/download like FTP client/server
- Embedded features in the Gateway Service (IoT Hub for Microsoft Azure)
- Embedded options for container repository (for example Azure Container Registry [ACR]).
- Custom Solutions
If the IoT devices run Linux-based OS commands like apt-get could be used to download packages from different repositories.
The general consideration is related to the security and flexibility to extend these tools.
Solutions with FTP server are possible option, but it depends on the current implementation and configuration. Possible issues are again security, scalability, high availability, multi-tenancy.
IoT Gateways like IoTHub can support embedded features to transport updates: It could be using messaging with additional logic to split and join the package / container parts, because of the message size limitations (256KB for IoTHub).
There are some new feature like IoTHub Device Streams (in preview), considered mostly for remote monitoring which can be used for software update if there is not very high number of devices per IoTHub .
IoTHub Device Streams
Container registries like Docker Registry (Azure Container Registry (ACR) for Azure) support build-in functionalities for upload/download containers with required security and RBAC.
Custom solutions: this approach includes any kind of custom implementation (for example Restful services), which can be used to download software updates.
4. Secure communication: secure communication includes several aspects:
- Communication protocol
- Security access to resources in the repository, usually based on RBAC (role based access control)
- Security on the package / container level – validation f the files identity (digitally signing the files, or validating the checksum)
Software update concept:
There are two common concepts, related to software download when you have solution which need to update the software on IoT Devices:
- Software update using a separate communication channel than the major one, used for messages via Gateway service (Azure IoT Hub).
- Software update design when you have a packages transfer via the gateway service (IoT Hub.)
The first approach requires to configure a separate endpoint for download the packages from the back-end.
This endpoint need to be secured and configured separately . Pure download implementation is simpler, but the solution needs to support different channels and separate configuration for download and messaging.
Software update concept using a separate communication channels for messages and for software update packages and containers.
To do firmware update using only what’s available publicly today in IoT Hub, you’d probably start by sending a cloud-to-device message to your device. Of course, exactly how you go about downloading and updating the firmware after that is specific to your device and scenario.
This approach is more clear from the architectural point of view, because only one communication channel is required, but it needs additional logic to split and merge updates.
5. Synchronization between devices and back-end about upcoming updates.
The most often used approach is with so named “current configuration” and “desired configuration”.
- Desired configuration is the planned state after the software update
- Current configuration is the current state of the software on the device.
This synchronization can be done using direct messages between devices and the back-end or with “device-twins”: configurations, which are uploaded asynchronously into the Gateway Service (IoTHub) and both sides: devices and the back-end can check the available configurations with no need to send direct messages.
Device twins concept
6. Software Bundling: this is the approach to group updates on the logical (sometimes also in the physical) level into so named “software bundles.
7. Campaign Management
To have the full coverage of the concept of software update we need to discuss also non-functional requirements like performance, scalability , availability etc. and the related to these requirements functionalities like campaign management, which we will cover in some of the next articles.