Choosing the Right IoT Fleet Management System: A Look at Torizon, Balena and Mender

During its lifetime, a connected device will need to be provisioned, deployed, maintained and eventually, decommissioned. Choosing the right solution with the right architecture is important to safeguard the long-term management viability of your fleet of connected devices. But there’s an issue: these systems are complex and there is no single, ideal system for IoT devices.

So how do you select a system that is right for your business? You’ll need to carefully weigh the pros and cons of each option as there are trade offs with any system. In this blog, we explore in more detail Torizon, Balena and Mender – complete solutions capable of building, deploying and controlling IoT devices in a field. These solutions have mature infrastructure that can work with all leading cloud providers. 

(For more on IoT device fleet management solutions, you can learn about creating a robust solution with Azure at our October 27, 2022 webinar.)

Popular OTA Platforms

 

• Torizon is a popular open-source OTA platform built with the Yocto Project, and based on the Toradex Embedded Linux BSP.
• Balena is a complete set of tools for building, deploying, and managing fleets of connected Linux devices.
• Mender is a secure, robust, open source end-to-end over-the-air (OTA) software update manager for IoT devices.

Torizon Solution

https://developer-next.toradex.com

Torizon is a Linux-based software platform that simplifies the process of developing and maintaining embedded software, and helps to design a scalable and easy-to-maintain software. Torizon, a product of Toradex Inc., is quick and easy to configure for various use cases. Torizon's primary component, TorizonCore, is a minimal embedded, pre-built binary Linux image featuring distribution, a container runtime and components for secure remote OTA updates. For developers, Torizon offers full integration with Visual Studio 2019.

TorizonCore is built from Yocto Project/OpenEmbedded and utilizes over 200 open source projects that all have licensing that falls under the Open Source Initiative guidelines. The only proprietary pieces are from the SoC vendor and Torizon actively works to find OSS alternatives.

With Torizon, you can develop an ecosystem to manage a fleet of devices on a large scale. Torizon uses Docker software, giving a device manufacturer access to the Docker hub and thousands of ready-to-use containers. It is built for products in mission-critical industries like medical and transportation where failure is not an option.

A fundamental advantage of the Torizon platform is the possibility to work on application architectures based on multiple containers. As mentioned in the first blog in this series, Torizon uses Aktualizr and OSTree technologies. OSTree is the preferred technology to deploy Over-The-Air updates for Toradex Modules. Aktualizer, an open-source implementation of Uptane (a secure software update system design), is used as a supervisor, checking authentication and integrity, handling the security part of OTA.

The key components of Torizon include Aktualizer, OSTree, Server and a set of applications.

Aktualizer 

• Device-side update client
• Secures all updates end-to-end
• Guarantees OTA integrity and confidentiality
• Implementation of Uptane, an open and secure software update framework design that protects software delivered over-the-air to automobile electronic control units

Note that Aktualizer is the de facto standard for software updates in automobiles. As a super class of Aktualizer, Uptane utilizes multiple servers, or repositories, to provide secure updates for vehicle components through the validation of images before downloading.

OSTree

• File-based (filesystem, trees using Git-like model)
• Can roll out to working filesystem and tree via bootloader
• Can update single files
• Supports extended filesystem attributes

Server

• Cloud-hosted service (e.g. GCP, AWS, Azure)
• Kubernetes cluster (a set of nodes that run containerized applications) 

Applications

• A Docker-compose file is used to build
• OTA service downloads the file and then pulls images from Docker repository
• Uses custom Yocto to build container image; Torizon Core Builder to build container image

Here are some resources around Torizon for you to explore:

• Torizon OTA solution based on OSTree
• Uptane, underlying OTA subsystem for Torizon
• Torizon development resources

Balena Solution

https://www.balena.io/

Balena platform follows the same concept as Mender and sets up its own host OS. The greatest difference is that Balena establishes its own build server, where images are built and delivered to the fleet. Therefore, the Balena platform is more aligned with the Torizon concept than with Mender, in which the image-building process is segregated from the main platform. 

Devices in the Balena ecosystem run BalenaOS, a Yocto build-based host operating system, which comes packaged with a lightweight, Docker-compatible container engine called BalenaEngine. Once a device is set up with the host BalenaOS, the user can push code to the Balena build servers, where it will be packaged into containers and delivered to a fleet.

The Balena platform offers tools for building, deploying and managing fleets of connected Linux devices.

This diagram outlines the Balena platform’s capabilities. Note that although this diagram lacks integration points with cloud providers to offer telemetry data processing, Balena provides many integrations with major cloud providers.

 

Let's walk through this diagram:

1. The built image containing the BalenaOS and applications is pushed to the registry
2. The Balena API Gateway brokers messaging from the device fleet to the platform
3. HTTP endpoints connect to the Balena Agent and scan diagnostic information

A key feature of Balena is a provisioning key for IoT devices being embedded into the BalenaOS image to be uploaded to a fleet. When the device boots up for the first time, it uses the provisioning API to register itself with the Balena OTA platform. A new device entry on the Balena backend is created and a device API key for this device is generated. So, provisioning flow is platform-specific and is vendor-locked.

While Mender is an extendable, open-source OTA platform, it lacks the completeness and maturity of Balena with its full-cycle device management: build, deploy, provision, control, decommission etc. But, again there are trade-offs. Balena imposes development constraints like vendor-locking to its Balena OS, and makes it impossible to add new features or make any amendments to existing flows. This makes Balena a good ecosystem to build fast-to-market IoT solutions.

OpenBalena

Responding to the market pressure over vendor locking, Balena recently unlocked its platform for the development of open stacks based on its OpenBalena software, which combines Open Balena (GNU AGPL v3) and Balena OS (Apache license 2.0).

OpenBalena is a platform used to deploy and manage connected devices. Devices run the balenaOS, which is specifically designed for running containers on IoT device. You can use the Balena interface to complete a variety of tasks, such as configure application containers, push updates and view logs. 

(Note that open source options may be limited to minimal IoT business requirements so be sure to check the capabilities of any open source version before finalizing IoT system design.)

Though the platform is still in beta, which can be a limiting factor for enterprises interested in working with Balena, OpenBalena provides developers with the ability to easily manage fleets of devices on their own, mitigating fears of lock-in. Deployment of OpenBalena enables developers to create and manage a fleet of devices running on its own infrastructure, on premises or in the cloud. 

OpenBalena and BalenaCloud share the same core technology with some key differences. For instance, OpenBalena is self-hosted whereas BalenaCloud is hosted by Balena, which in turn handles security, maintenance, scaling and reliability of all the backend services. OpenBalena is also single user, whereas balenaCloud supports multiple users and organizations. (Note that OpenBalena users can migrate to BalenaCloud if they need a ready-to-use, commercially supported platform but BalenaCloud users can’t migrate to OpenBalena.)

Here are some resources around Balena for you to explore:

• Fleet provisioning demo with Raspberry Pi 3 and Node.js
• Balena building and fleet management flow
• Open Balena beta

Mender Solution

https://mender.io/

The Mender server is built on a microservices architecture licensed under the Apache License v2. Mender efficiently eliminates bottlenecks as services can be automatically scaled independently, in small incremental steps with minimal overhead. It also supports updating all device software and gives customers the freedom to customize the update and installation process to fit their specific workflow.

The combination of a hosted service and self-managed server gives full flexibility to its users, allowing them to sell their devices to both customers that allow for public internet access and to those that do not (e.g. hospitals, military). Mender supports a time-based and phased rollout, which can greatly reduce risk by dividing a software update deployment into time-delayed phases with a customizable share of the devices being updated in each phase.

Mender automatically assigns the right delta update to any given device, based on the software release the device is currently running. When a device checks for an update, the Mender server will automatically decide which software code to give to the device based on the version the device is already running. 

(Delta updates provide significant savings in both bandwidth and install time because only the difference between the new and the old root filesystem is transmitted to the device. A delta update can therefore be significantly smaller than a regular update. In every other regard, this is the same as doing a regular system update, with atomicity, integrity, rollback and signature support included.) 

It will select a delta update if available for the release the device is running, but also supports falling back to the full image if no delta update is available. This ensures that all devices get updated and minimizes the bandwidth needed based on the delta updates that are available on the server. It also saves time and reduces deployment errors with incompatible delta deployments.

 

Let’s walk through this diagram:

1. The client device authenticates and pulls for the new applications and OS versions.
2. The API Gateway mediates the connection to the Mender server network and routes requests to internal services.
3. The product of the Mender Build and Deploy flow is an artifact stored in either ‘S3’ or ‘Minio’ durable storage.
4. The Mender server stack is presented by several container-based applications running in a Kubernetes cluster, either in-house or in one of the clouds (e.g. AWS, GCP, Azure).

Mender’s provisioning with symmetric key

A symmetric key is used both to encrypt and decrypt information. To decrypt information, someone must have the same key that was used to encrypt it. This symmetric key provisioning offers several benefits:

• Simplifies provisioning of device between Mender and IoT hub
• Eliminates need to manage device registrations in multiple places. Once registered in Mender, it is also registered with the IoT hub service
• Easy to use thanks to a single UI to access and control information about a device (For instance, with Azure Device Twins in Mender users can have all the information about devices in a single panel, configure each device, and update them directly from Mender.)
• Increases security by simplifying device-side credentials management
• Reduces operational complexity 

Here are some resources around Mender for you to explore:

• Integrate IoT cloud analytics and OTA updates with Google and Mender.io
• Tool to convert pre-built disk images (Debian, Ubuntu, Raspbian, etc) to Mender-compatible images
• Build and install Yocto image with Mender server

The Takeaway

An effective IoT fleet management system provides robust management of the update process, a process that ideally should be seamless and unobtrusive to an end-user. But achieving that is quite complicated. Many IoT ecosystems are found to lack scalability, which is a leading cause for IoT project failures. Another is the traditional siloed approach – OTA software and device management solutions are typically segregated from IoT cloud service providers even though devices need to be connected to both services simultaneously. 

The right fleet management system can greatly enhance your business, while the wrong one could hinder your IoT success. While there is no universal, perfect fleet management system for IoT devices, there are a variety of solid options depending upon your particular business needs and development philosophy.

In this blog, we’ve explored a few of the most popular platforms. However, each of these is more complex than we could cover here. Consequently, we encourage you to do your own research into these platforms, as well as investigate any others that might be better tailored to your specific product requirements. If you’d like assistance evaluating these options or examining any facets of an IoT device fleet management solution, please reach out to us. 

For more on IoT device fleet management, register for our October 27, 2022 webinar Create a Robust Solution with Azure.