User Tools

Site Tools


CIP Comparison report

This document compares software update tools that are suitable to implement the CIP software updates architecture. For a thorough comparison of open source software update tools please check the Comparison references section below. We compared the tools from different points of view such as:

  1. network and storage efficiency
  2. ability to integrate with Debian-based build tools used in CIP Core (e.g.: Deby, ISAR)
  3. community and member's expertise
  4. support for local and remote updates
  5. security support (encryption, digital certificates, integrity)
  6. extendable with scripts

Server software


Mender.IO server

HERE OTA community

Custom Http server

Client software

SWUpdate + librsync

  • 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
      • Building SWUpdate 2019.04 with 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)

  • 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


  • 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


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 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:

Comparison references

civilinfrastructureplatform/cip_comparison_report.txt · Last modified: 2019/05/14 02:12 by daniel.sangorrin