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.}}
==Introduction==
In the last years, we have witnessed the dawning of the IoT age: billions of independent embedded computing devices capable of communicating over a network without requiring human-to-human or human-to-computer interaction have spread all over the world. The term “thing” "thing" designates a wide variety of systems, ranging from medical devices and autonomous vehicles to smart sensors and wearable technologies (just to give a few examples). In other words, both consumer and industrial electronics markets have been flooded/involved by this new technological trend. When it comes to the industrial context, a typical IoT ecosystem consists of sensors that gather data from the environment and actuators ready to intervene according to the acquired information. The collected data can be shared between devices inside the network through
a so-called edge device such as an IoT gateway.
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==
The following picture illustrates the overall system architecture of the solution.
[[File:MISC-TN-012-bd.png|center|thumb|600px|Block diagram of the overall system architecture]]
Basically, it consists of two pieces of software:
*[https://www.eclipse.org/hawkbit/ hawkBit] running on the cloud side (version 0.3.0 was used)
*[https://sbabic.github.io/swupdate/ SWUpdate] running on the edge device (version 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 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.
[[File:MISC-TN-012-symmetric-update.png|center|thumb|Symmetric update scheme]]
Symmetric updates rely on two mirror copies, 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 and it runs on the gateway as a daemon.
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.
