If you’ve started working on an embedded software project, you’ve probably reached the point where you looked around for an update system, and found out that there isn’t a lot of great tooling out there. Our experience has been that people tend to implement software updates on a case-by-case basis, leading to solutions that are specific to the target platform, proprietary, brittle, or insecure—​or sometimes all of the above. HERE OTA Connect provides an open source solution that you can plug-and-play into your build process.

Let’s look at the parts of the system, and how they fit together.

Yocto

The Yocto Project is an open source collaborative project that provides standardized high-quality infrastructure, tools, and methodology to help decrease the complexity and increase the portability of Linux implementations in the embedded industry. It enables its users to build custom operating systems using specific recipes for embedded devices. Most commercial embedded Linux distros already use and/or support Yocto, including Wind River and Enea. It’s backed by major hardware vendors like Intel, AMD, Freescale, Mentor, Texas Instruments, and many others. If you need a highly performant customized Linux for your embedded device, whether it’s IoT, automotive, or other kinds of mobility devices, the Yocto project is probably what you’re using.

HERE Technologies has created a meta-updater layer for Yocto, making it easy to get over-the-air update support into your devices. In many cases, it’s as simple as adding meta-updater and a board support integration layer to your project and re-running bitbake. The main features of the meta-updater layer are OSTree and our OTA update client, aktualizr. OSTree handles the filesystem versioning, and aktualizr communicates with the server, downloads updates, and cryptographically verifies them following the Uptane framework.

OSTree

OSTree is an open-source tool that combines a "git-like" model for committing and downloading bootable filesystem trees, along with a layer for deploying them and managing the bootloader configuration. It is actively developed and support by Red Hat, and used in flatpak and Project Atomic.

For more on why OSTree is the best tool for the job of doing embedded device updates, take a look at Comparing full-filesystem update strategies.

Doing It Wrong™: Bad choices for embedded updates
  • Package managers

    Hey, every Linux distro does it this way—​why don’t I just use a dpkg/rpm/apk-based package manager for my embedded system? I can control it remotely, and as long as I maintain the same sequence of package installs from the same sources, I should have perfectly consistent filesystems, right?

    The problem with this approach is that updates aren’t guaranteed to be atomic, so it’s quite easy to get the system into a state that requires user intervention to fix, especially if it’s rebooted during an update. That might be fine on the desktop or on a server where there’s a reasonable expectation that a user could intervene, but it doesn’t work for embedded devices.

  • "Update Mode" and similar designs

    The idea here is that you boot into a mode that allows the root filesystem to be overwritten, either via a pre-downloaded image or via something streamed over the network. Fortunately, we rarely see this design in the wild anymore, with the occasional exception of industrial control systems where the update process is closely supervised. When we do see it, it’s typically a legacy of days when microcontroller flashing would be done in person, with a new image streamed over a serial interface to overwrite the old system. This is a very poor choice for embedded, because of the risk that users may disconnect the device while the new image is being flashed, potentially bricking the device or requiring a more difficult intervention to fix. Lower-end home routers and DSL modems sometimes go this route; doing a quick Google search for "firmware update bricked router" should show why this is a bad idea.

TreeHub

Since OSTree is "git-like", you can probably imagine that you can have remote repositories. TreeHub is exactly that. It’s seamlessly integrated into the meta-updater layer and into the HERE OTA Connect site itself. Your builds get automatically pushed to TreeHub as soon as you make them, and you can use OTA Connect to wirelessly update your devices—​one at a time, or in targeted campaigns. You can even set certain devices to automatically pull updates from TreeHub as soon as they’re pushed, and stop wasting time re-flashing the units on your test bench every time you build new code.