dave_user, Administrators
5,138
edits
Changes
no edit summary
{{InfoBoxTop}}
{{AppliesToSBCSPG}}
{{AppliesTo SBC Lynx TN}}
{{AppliesToIoT}}
{{AppliesTo IoT TN}}
{{InfoBoxBottom}}
{{WarningMessage|text=This technical note was validated against specific versions of hardware and software. It may not work with other versions.}}
architecture, without sacrificing security and reliability.
This Technical Note (TN) shows how to implement a secure OTA software updating system for [[:Category:SBCSPG|DAVE Embedded Systems' Industrial IoT gateway named SBCSPG]]satisfying the aforementioned requirements.
==Overall system architecture==
Basically, it consists of two pieces of software:
*[https://www.eclipse.org/hawkbit/ hawkBit] running on the cloud side (version TBD 0.3.0 was used)*[https://sbabic.github.io/swupdate/ SWUpdate] running on the edge device (version TBD v2020.04.0 was used).
==Gateway and server configurations==
Regarding the gateway's software configuration, it resembles the one described [[MISC-TN-004:_Running_Debian_(armbian)_on_SBCSPG|here]]. In this case, however, a symmetric update scheme was adopted. As such, the resulting non-volatile memory partitioning is a little bit different. It is shown in the following image.
For the sake of simplicity, the implemented first chosen update mechanism aims to update the Linux kernel image (along with the associated device tree blob) and the root file system as a whole. This approach is called monolithic update.
Symmetric updates rely on two mirror copies of the system, each comprising Linux kernel and root filesystem in this specific case. They are labeled as A and B in the figure. If A is running, an incoming update overwrites B. Then the system reboots, switching to B. The two copies swap their roles after every successful update. Clearly, the system continues to run the same copy whenever a failure occurs: in any case, the device’s integrity is ensured. The most pleasing benefit of symmetric updates is that they allow the device to continue executing its usual tasks since the inactive copy is updated separately in the background. Furthermore, only the minimal downtime of a single reboot is required. There are two downsides as well: the storage space needed for a redundant copy is doubled compared to the asymmetric scheme and the large size of the update packages can put a strain on the network infrastructure. The latter can be mitigated by sending only the file-system blocks that have changed with respect to the previous version (binary delta update).
SWUpdate was built natively. It run and it runs on the gateway as a daemon. TBD
With regard to the hawkBit server, a virtual machine running the Lubuntu 18.04 distro was used.
==Testing==
The following image shows the messages printed by SWUpdate when started.
[[File:MISC-TN-012-swupdate SBCSPG.png|center|thumb|600px|SWUpdate running on SBCSPG]]
The following picture illustrates a screenshot of the hawkBit's console. This interface allows to configure the update policies for the entire fleet of devices and to monitor the past, current, and scheduled roll-out operations. Several options are available, for example for defining different policies on a geographical basis.
[[File:MISC-TN-012-hawkBit SBCSPG.jpg|center|thumb|600px|Screenshot of the hawkBit's console]]
This specific screenshot shows several attempts to deploy the software to the target. Some of them were completed successfully, some were not. For instance, to verify the capability of the target to resume an interrupted updating, the gateway was turned off abruptly in the middle of downloading or flashing.
To test the overall remote update mechanism, appropriate images have to be prepared. Such images include a file listing platform-dependent operations required to apply the update on the device side. This file is processed by SWUpdate that carries out such operations.
