====== CIP Comparison report ======

This document compares software update tools that are suitable to implement the [[civilinfrastructureplatform:cip_software_updates_architecture|CIP software updates architecture]]. For a thorough comparison of open source software update tools please check the [[cip_comparison_report#comparison_references|Comparison references]] section below. We compared the tools from different points of view such as:
  - network and storage efficiency
  - ability to integrate with Debian-based build tools used in CIP Core (e.g.: Deby, ISAR)
  - community and member's expertise
  - support for local and remote updates
  - security support (encryption, digital certificates, integrity)
  - extendable with scripts

===== Server software =====

Hawkbit
  * supported by SWUpdate and RAUC
  * Written in Java
  * Docker compose available
    * https://github.com/eclipse/hawkbit/tree/master/hawkbit-runtime/docker
Mender.IO server
  * written in Go
  * requires some effort to support it from SWUpdate
  * microservices architecture and docker-compose
    * https://github.com/BaseflowIT/mender-server/blob/master/docker-compose.demo.yml
HERE OTA community
  * microservices architecture and Kubernetes
    * https://github.com/advancedtelematic/ota-community-edition/blob/master/config/images.yaml
Custom Http server
  * Supported by SWUpdate
    * https://sbabic.github.io/swupdate/suricatta.html#support-for-general-purpose-http-server

===== Client software =====

SWUpdate + librsync
  * https://sbabic.github.io/swupdate/swupdate.html
  * Good points
    * modular: you can enable/disable each function
    * good community: Stephano, Denx(u-boot)
    * CIP members experience (Siemens)
    * supports yocto (meta-swupdate) and Debian (on-going: waiting for libubootenv replacement)
    * low bandwidth (librsync deltas)
    * u-boot interface
    * can work with block and file-system trees
  * Bad points
    * hard to manage updates from v1 to v5 directly
    * depends on a u-boot library that needs to be rebuilt for each target (on-going: replacement  https://github.com/sbabic/libubootenv).
      * Building SWUpdate 2019.04 with [[https://github.com/Kynetics/meta-updatefactory/commit/c4c25b21d3ed4ae15f9716769c2644953e8eedb3#diff-6a1eb0b91b36c4c636f9fa5b23f5514bR53|CONFIG_UBOOT_NEWAPI]] will make use of the standalone libubootenv library, and will read default initial environment from "/etc/u-boot-initial-env".

RAUC + Casync (command)
  * https://github.com/rauc/rauc
  * https://rauc.readthedocs.io/en/latest/
  * Good points
    * Casync can update from version 1 to version N
    * Casync divides images in chunks (delta-like updates)
    * Casync supports file trees with fs metadata and block images
    * Casync has good storage properties thanks to reuse of chunks
  * Bad points
    * Casync has many dependencies and requires new library versions
    * Casync needs to calculate chunks on the target device
    * The target device needs extra storage for the chunks store
    * Casync is not well integrated into RAUC
meta-updater
  * https://github.com/advancedtelematic/meta-updater
  * Good points
    * uses deltas through OSTree (low bandwidth)
    * integrated with yocto
    * rollback capacity
    * atomic updates
    * uses 1 partition and 1 ramdisk (low storage required)
    * supports u-boot
  * Bad points
    * hard to use in a non-yocto build system
    * hard to manage updates from v1 to v5 directly
    * does not support efibootguard
    * has intrusive dependencies (meta-python)
    * does not support A/B partitions updating

===== Conclusions =====

We compared several methods and read other comparison reports (see "Comparison references" below). All methods have their own advantages and disadvantages. For the next phase, we decided to go for the "SWUpdate + librsync" method because it satisfies the requirements specified by the [[CIP Software Updates Architecture| CIP Software Updates Architecture]] and Siemens has important experience using that method. We also decided to use Hawkbit on the server side for our initial prototype because it is known that SWUpdate works with Hawkbit. Having said that, the project will be open to other update methods and tools and we welcome any contribution in that sense.

Finally, here is a document that contains more detailed comments and a table where CIP members compared several software update methods:
  * https://docs.google.com/presentation/d/1NIjspcmjo2w6FxK64WdysfFG4jayxL0q0lU_PP569k8 (software update mechanism)

===== Comparison references =====

https://elinux.org/Secure_OTA_Update
https://wiki.yoctoproject.org/wiki/System_Update
https://mkrak.org/wp-content/uploads/2018/04/FOSS-NORTH_2018_Software_Updates.pdf
https://events.linuxfoundation.org/wp-content/uploads/2017/12/Strategies-for-Developing-and-Deploying-your-Embedded-Applications-and-Images-Mirza-Krak-Mender.io_.pdf
http://events17.linuxfoundation.org/sites/events/files/slides/ELC2017_SWUpdate.pdf
https://events.static.linuxfound.org/sites/events/files/slides/linuxcon-japan-2016-softwre-updates-sangorrin.pdf
https://events.linuxfoundation.org/wp-content/uploads/2017/12/ELCE-2018-Update-Tools-BoF_Jan-Lubbe.pdf
https://elinux.org/images/f/f5/Embedded_Systems_Software_Update_for_IoT.pdf
https://elinux.org/images/3/31/Comparison_of_Linux_Software_Update_Technologies.pdf