EN 
DE Step by step to a finished solution
Author: Willi Flühmann, Noser Engineering AG
Contribution – Embedded Software Engineering Congress 2018
Networking is becoming increasingly important for embedded systems to further enhance their usability and open up new application areas. This often means connecting to the cloud, which, in addition to increased complexity, necessitates support for common communication protocols. The simplest way to achieve this is by using a platform like Linux with its rich ecosystem of ready-made, standardized software components.
In such an environment, the possibility of an update has become very important:
- Complexity makes systems prone to errors: Regular improvements become necessary.
- Networking makes systems directly vulnerable: security gaps must be able to be fixed quickly.
- Standardized software components enable large-scale attacks: components must be regularly updated to newer versions.
- Fast-moving protocols and services: To maintain compatibility, adjustments to communication are sometimes necessary.
Experience has shown that cooperating with users during updates is not easy. If an update involves many manual steps, extended downtime, or even requires technical expertise, then the willingness to update decreases, and many systems remain in an outdated version.
Promising to deliver new, useful features from time to time can improve user motivation, but then it becomes a long-term commitment with additional effort.
Furthermore, some embedded systems are installed in inaccessible locations without their own user interface, making ongoing maintenance more difficult. Therefore, an update mechanism that is as convenient and automatic as possible is essential.
Update in parts or as a whole?
Embedded systems, unlike desktop systems, often have higher demands on reliability and stability. A robust and comprehensive update mechanism is expected. A package manager that updates software components individually typically does not meet these expectations. In particular, it lacks a way to perform fundamental updates (e.g., major changes to the directory structure, significant jumps in the Linux version) and execute them atomically.
Furthermore, it is important that the versions of the software components are well-matched and that only a few, thoroughly tested combinations are used. Ideally, the file system should contain no remnants of the previous installation, thus eliminating uncertainties. This keeps the number of configurations in the field manageable and limits the potential for errors.
All of this suggests that the entire system (complete image) should be updated.
Concept for flash partitioning
For a robust update process, a crucial decision must be made regarding the allocation of the flash memory. Several concepts are conceivable for this; see Table 1 in the [document/section]. PDF.
In our project, we opted for the A/B approach because sufficient flash memory is available. This approach is now recommended for modern devices (e.g., "Seamless Update" from Android version 7.0 onwards).
Components of an update solution
The implementation of an automatic software update must take place at different levels, see Fig. 1 in the PDF.
The architecture of embedded systems (bootloader, partitioning, existing services and software components, cloud connectivity, etc.) is usually tailored to the specific application, even when Linux is used. It seems difficult to offer an all-in-one solution for software updates in such an environment, which is why there are hardly any.
Comparison of existing solutions
Nevertheless, there are ready-made software components for the update that have covered at least some of our requirements:
|
|
Mender |
SWUpdate |
RAUC |
| developer | Northern.tech | Stefano Babic (DENX), among others.
|
Pengutronix, among others. |
| First release (GitHub) | 2017 | 2014 | 2015 |
| License | Apache | GPL | LGPL |
| Language | Golang | C | C |
| cover | Complete solution from bootloader integration to cloud server | Core component in Linux for executing the update based on a flexible definition and scripts in the update image | Core component in Linux for executing the update, flexibly configurable, supports multiple concepts; command-line tools for image generation and debugging/intervention of the system.
|
| Evaluation | Complete solution, but less flexible as certain components are predetermined (U-Boot bootloader, Mender server); less widely used language Golang | It's better understood as a modular system for integrating various bootloaders or cloud connections around the core component; it requires significantly more effort on your part, but can be well tailored to your own environment. | Similar to SWUpdate, but offers more tools and a stronger focus on security; somewhat more predefined (more abstract model, less scripting), but compensated for with more configuration options. |
Table 2: Comparison of existing solutions
All three solutions are under active development (as of autumn 2018) and offer Yocto integration and commercial support. In our project, we opted for SWUpdate. RAUC would also have been a viable option.
Due to the requirements of our project, a custom implementation based on MQTT and HTTP was chosen for the provision and control of updates on the server side.
A server component often chosen in similar projects is Eclipse hawkBit. Both SWUpdate and RAUC offer integration with hawkBit.
Step-by-step to a complete solution (with SWUpdate)
With the chosen A/B approach, two complete software copies would need to fit in the flash memory. To simplify matters, the kernel and the device tree are no longer kept in separate partitions, but are integrated as files into the root file system, so that now exactly one partition is needed per software copy (see Fig. 2). PDF.
The application data is stored in a separate partition so that it is preserved during an update.
Since we used raw NAND flash in our project, the partitions were mapped to UBI volumes (except for the bootloader) and the UBIFS file system was used within them.
The update is delivered as an image file, e.g., with the extension ".swu". It contains, as a compressed archive in cpio format, all necessary files such as scripts and an image of the partition to be updated.
Furthermore, it contains a file called "sw-description" which describes the actions to be performed for SWUpdate. It might look something like this:
After the affected partition is updated, a post-install script is executed that swaps the roles of the active and inactive partitions. In the case of UBI volumes, this can be done simply by renaming them:
All the files mentioned above (sw-description, partition image, post-install script) are packed into an image update using the following lines:
The next important point is the distribution of updates. For this, the device establishes a connection to the server to determine if an update is available:
In our project, the target version (defined on the server for each registered device) is compared with the current version (stored as information somewhere in the root file system). If there is a discrepancy, the update process is initiated.
The following commands are executed during the update process, as shown in the figure. PDF.
There are many more points that could be written about here, but they would go beyond the scope of this article:
- Bootloader configuration
- Security
- Rollback to a previous software copy in case of late-onset errors
- Read-only file system
- Integration of SWUpdate into the Yocto build
- Data migration
Check out our blog: https://blog.noser.com/
Total expenditure
Implementing the discussed solution with SWUpdate requires a total effort of between 1 and 3 person-months across all levels, depending on the expansion stage.
author
Willi Flühmann works as a software developer and architect at Noser Engineering. An electrical engineer with 16 years of experience in software development, he has worked on numerous projects in both embedded and desktop applications. He is currently working on IoT projects and is also interested in security-related topics.
Open Source – our training & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of Open Source / Embedded Software Engineering.
Training & coaching on the other topics in our portfolio can be found here. here.
Open Source – Expertise
Valuable expertise in the field of Open Source / Embedded Software Engineering is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
