3. May 2023 By Stefano Fiorentino
How can over-the-Air Software Updates make developer's lives easier?
Software is everywhere. Embedded devices contain a lot of software. Unfortunately, what happens a lot: Once it’s live, you’ll discover bugs. Having a FOTA-first mindset for your next device is a key point.
In this blog post, I will introduce you to one of the most used frameworks for firmware update under Linux: SWUpdate. This framework is maintained by Stefano Babic and is publicly available on GitHub. Used within the Yocto Project, it allows your team to easily establish a firmware update strategy for your product.
If you want to know why the Yocto Project is a power solution, read the blog post from my colleague. Have a look here.
By the way, you might also be interested in our landing page on the topic of "Embedded Software Solutions by adesso ".
As a well-established best-practice, this product feature is one of the first (if not the first) features your product should have, hence the term FOTA-first. This allows your team to easily update the device with new versions during development, your QA department to stay up to date with the developments, or whatever released version they need to check, and as a side benefit, you’ll be testing several times this same feature, the update procedure itself, from the very early stages and during the complete product development.
In practical terms, updating the software of your device consists in having a new version of the software running on it. In the past, this was done by field service engineers. I have personally performed several software updates to huge manufacturing equipment, by manually swapping the complete hard disk with the old software with the new software version one. In smaller cases, such as vending machines, it was common practice to plug in the USB with the new software and reboot the machine. A pre-defined procedure during the boot process was responsible for checking whether the new software updates were present in the inserted USB memory. It is in this latter case, with the persistent memory installed in the device remaining the same, that several update strategies were implemented. We will concentrate here in the dual-copy strategy, which is the one we normally recommend whenever the device has enough storage space.
With the advent of IoT this procedure got the name of Over-The-Air update, meaning that both the information about the new software version, and the new software package itself, are shared with the device over the internet (i.e., without the need for activities in the field). Even though the trigger and the information sharing have changed a bit, the foundation of the available strategies remains the same, so let’s review one of them together.
The dual-copy strategy
In this configuration, your storage has enough space for two (almost) equal copies. If this is your case, you can guarantee that you always have a working copy of the software on your device. In fact, in case of an adverse event during an update (e.g., a power cut), you can always fall back to the original version (i.e., the partition from which you started the update).
To provide this guarantee to your users, a copy of the updating software should always be shipped with all versions of the software, should always work, and there should also be a procedure to know which partition is running. This information can be provided by the boot loader, which is responsible to start the right software, and possibly recovering from a situation in which our software update procedure went wrong.
As a side note: To drastically minimize the possibility of file system corruptions, we usually recommend a read-only file system on the working copy of the software. That’s the main reason why in the Figure 1, along with the two application partitions and the bootloader, you can see a data partition, too. This is the only partition applications can write to and the right place to save custom configuration of the device. This has the side-benefit of allowing you to setup the firmware so that you can easily reset your device to the manufacturing status (i.e., factory reset) by simply erasing this data partition.
SWUpdate and the Yocto Project
SWUpdate provides a reliable way to update the software on an embedded system. This framework natively supports the dual-copy strategy. The resulting device has the important feature that the not running copy can always be updated by the software starting from the running copy. The maintainer of the framework has released a specific Yocto Project-compatible meta-layer that makes it even easier to integrate the needed tools into your firmware image: meta-swupdate. To help even more developers, especially those who are required to integrate these tools in devices’ firmware solutions, an additional meta-layer, the meta-swupdate-boards, has been published. This last meta-layer contains the configuration for the dual-copy strategy for the raspberripi3 machine, the one I started from to validate and write this article. If you want to know more, please refer here or contact my team at adesso Schweiz AG.
With from all these meta-layers provided by the framework contributors, it was straightforward to prepare a firmware update demo. In practice, by secure-copying the updated image to the writable partition (i.e., /tmp or /data folders) you can simulate the trigger given by your cloud vendor (e.g., device twin change notification in Azure IoT Hub) and the download of the new firmware in a given folder (this was completely out-of-scope for this demo). Once you have the new firmware version image saved somewhere on the device, you can leverage the swupdate-client to request the update to the daemon, and nothing else. SWUpdate will manage the actual firmware copy in the right partition and the reboot in the correct, updated, copy partition.
Conclusion
Preparing a firmware image has never been easier. To avoid the struggles of implementing a custom software update procedure, facilitating even more developers’ life and freeing time to concentrate on the actual business logic of the application, starting your next product development from the implementation of the chosen software update strategy is a must. Leveraging all these community-backed implementations of common best-practices will help your team deliver more secure and maintainable products to the market on schedule. If you would like to have a live demo or a hands-on workshop, please contact us.
