What is the right strategy for IoT update management?

When designing and provisioning OTA software updates in IoT update management, it is important to think about the right strategy for deploying the updates to your device fleet. This is an essential step in figuring out how to build a management workflow for your IoT fleet. It is important to understand the distinct nuances of system updates and application updates and which ones are most suitable for your particular workflows and routines, the size, and characteristics of your device fleet. Developing IoT devices properly, in a robust and secure fashion, requires this meticulous strategic mindset. Firstly, let's get a clear understanding and definition of the two different types of update approaches. This is important to consider upfront as you think about how to do IoT.

What is a system update in IoT update management?

A system update is defined as an update of the entire (root file) system of a device. In a system update, the entire system partition is overwritten and this includes any changes since the last update. There are several approaches to performing a system update. You can use an A/B system update such as the one shown in the diagram below. The second approach is to use a rescue system and this is an asymmetric updating approach. The third is to consider streaming compared to local storage.

Pros and cons of system updates in IoT update management

System updates have several advantages. They are very robust as there will be no partial installations, and a rollback will occur in the case of an update failure. You can also achieve a fully consistent fleet where the exact same software is updated on all devices. You can also ensure a seamless transition from testing the update to rolling out in the production devices. The drawbacks or cons of system updates is that they are resource intensive to design and deploy. There may also be challenges with network connectivity where having to deploy full images over limited cellular networks such as LTE 4G or satellite may be challenging from bandwidth and data cost perspective. Especially if the device fleet is large scale. System updates are best used for the updating of critical software, for example, the kernel. System updates are also very good for updating interdependent software - libraries and application frameworks; and for updating the software that all or most of the devices in the fleet should run. They are also most suitable for device fleets with less frequent software update schedules, let’s say for instance updates done on a quarterly basis.

Definition of an application update in IoT update management

An application update is an update to a single application running on a device. The application may reside on a system or independent partition. There are many different types of application updates. The main ones to consider are a) Containers which are considered extremely robust b) file updates which are also considered to be fairly robust. c) directories updates which are considered to be not robust, rather fragile, and finally d) package managers which again are considered to be fragile and ill advised to pursue.

Common workflows for system and application updates in IoT update management

Finally, let’s consider the common workflows in the field for system and application updates in IoT update management. The first is the approach that has been most commonly taken in the embedded world. It involves performing system updates only, and to include applications there. The second approach is to have the system update and overwrite application updates. This helps achieve consistency eventually, let’s say on a quarterly basis. It also facilitates fast application updates in-between these quarterly milestones. The third approach is to make the explicit choice to perform system and application updates independently of each other. So this would involve storing the system and applications on different partitions. Then separate teams can be responsible for each type. In this scenario, there is a risk and a possible downside where version sprawl could become an issue for applications.