Best Methods To Updating Embedded Linux Devices

Before you can dive into over-the-air (OTA) updates for your Internet of Things (IoT) Linux devices, it’s important to understand that there are differences between these devices. In order to make sure that your Linux devices are updated correctly, you’ll need to use the best methods available for updating embedded Linux devices.

That’s exactly what we’ll cover inside this comprehensive guide.

Understand the differences between OTA updates on IoT devices (plus any other device)

No matter what industry your internet-connected device is used for, OTA updates will be required, and not just to your IoT devices.

What constitutes an OTA update? It’s easier to explain these using device examples. Your smartphone receives OTA updates all the time. Servers can be maintained through OTA mechanisms, including those being supported remotely. It doesn’t matter what the device is, the way they receive an OTA update is the same per device. So if a server received an OTA update a certain way, other servers receive these updates exactly the same.

In comparison, when you look at the IoT sector, this is entirely different. Devices behave and work differently which means that an OTA update needs to be generic enough to handle any situation.

To help determine the method of an OTA update, these questions should help when it comes to your IoT products:

• Does the product intend to be utilized by an end-user or to work autonomously?
• Does the product operate 24/7?
• Is the product’s main power source a battery?
• Does the product have a stable internet connection? Is it connected to a cellular provider or a cable one?

Once you’ve answered these questions, you’ll then be able to determine the mechanism for how an OTA update will be implemented on your IoT product.

One thing to keep in mind with your IoT device is that there is no one “on-hand” to restart the device or call a support center. In comparison, servers and mobile applications are different and can be restarted. So if an update fails, how will the IoT device be updated?

Often, you can’t even get close enough to the IoT devices out in the field, which can lead to potential damages. Downtime for an IoT device can literally cause real harm. What if a factory could no longer continue producing because a stuck assembly line switched off due to a failure in a software update?

This is why it’s important to use the best method for updating your embedded Linux devices the right way.

OTA updates approach for IoT and connected devices

OTA updates approach for IoT and connected devices

So while there are risks associated with sending OTA updates, every IoT manufacturer that offers a smart product knows that they are going to need to deliver regular OTA updates.

There are two main ways that this might be achieved:

Utilizing the “old method” — Before internet connections were stable or available, the most common way of updating embedded products was physically updating the devices by connecting it with a cable to a computer, then “burning” onto its memory the new software update.

Obviously, this method is complicated and time-consuming, not to mention costly too, updates were deployed were few and far between. In some instances, some products would never receive any type of software update during their lifetime. This is definitely a fast way to become obsolete.

Once the internet came along and those products were instantly able to access the internet, many corporations were able to deploy OTA updates with ease, replacing the entire operating system with the new one in each update. 

And while this seems like a good idea, the only good thing about this approach is that there are no surprises. Whatever existed inside the old OS and inside the new OS is what will run on the device… as long as there are no issues with the update. 

There are a number of disadvantages with this method:

• Size of the update. Because the entire OS is sent, the size of each update can be hundreds of megabytes, sometimes multiple gigs. It can hinder deployment time but the largest issue is that it will use a lot of internet data. Most IoT devices are connected to the internet via a cellular network and may have low data plans. So deploying an update that replaces the whole OS doesn’t make sense.
• Data connection issues. If something goes wrong during the update, there is a risk that the device may not power on anymore. This is often referred to as a “brick” device. Some users may choose not to install an OTA update because of this risk.
• Updates require reboots. Restarting a device causes unwelcome downtime, sometimes resulting in loss of income due to the downtime (like in the factory example above).

So while the internet may have sped up accessibility and delivery of OTA updates, because of the challenges outlined above, the number of updates being sent using this method remains low.

What’s the “new” method — this might seem obvious, but this method is focused on only sending updates for part of the OS that needs changing. An example of this would be sending an update to the binary of your application or updating a module that your application uses. Compared with the old method, this option has minimal disadvantages. The only real one is if the updates are not organized by date (or some other clear identifier), it becomes difficult to know what update was sent to which device. 

There are many advantages to using this method:

• Update size reduces. In most instances, the size of the OTA update will be very small. Because you’re only sending part of the OS that needs to be updated, the update is tiny. So devices that have limited internet data plans can easily update their software without worrying about running out of data.
• No reboot required. In several conditions, applications don’t even need to stop running as the update is implemented. This prevents unwanted downtime and inconvenience to users.
• No bricked devices. 99% of the time, if an OTA update goes wrong, the device won’t end up being bricked. A smart OTA updates method recognizes when something has failed during the update and will revert to the previous, stable software version.
• Better security. Because updates can be deployed as often as needed, security protocols can be maintained, reducing the chances of breaches like those that happened with the famous Mirai bot.

Implementing OTA updates mechanism

While it’s entirely up to businesses to determine the best method for deploying OTA updates, for those who choose to use the old method with a Linux device that there will be some low-level programming required while modifying components such as the bootloader and the Linux kernel itself. 

There is an open-source project named swupdate, which provides a partial solution for this issue. You’ll notice that when you use swupdate, you are still going to need to integrate it and create features to meet your needs. If you plan to use the more popular method, there are two options for doing this effectively:

#1: In-house OTA updates mechanism

You and your team can create your own OTA updates mechanism in-house. But if you decide to do this, you’ll need to consider the following points:

• You’ll need to develop both client-side as well as server-side. The server should run on a cloud server, like AWS or Google Cloud. The client-side should run on your devices.
• Most IoT devices operate behind a NAT. This means that they don’t own a global IP address on the web, which means that you can’t contact them directly. The only way the server can communicate with the device is when they are first starting a conversation. Because of this, the mechanism would need to be set up where only the client sends the first packet to the server and not the other way around.
• You’ll need to implement a rollback system. It’s likely that an OTA update on your IoT device will fail at some point. This is why you’ll need to develop a smart rollback system that is designed to recognize failures and switch back to the old software prior to the update. With a rollback system, you’ll need to account for many edge cases. For example, if an update stops in the middle of a package upgrade, the rollback system will need to check and see if the old version of the package is still installed and working, and if it’s not, reinstall that version.

#2: Using a ready-to-use commercial platform

This type of platform offers a fast, stable, and secure solution with most of the functionalities you’ll need as outlined above. A potential commercial platform option is JFrog Connect. JFrog Connect’s platform provides a management dashboard for IoT and connected devices. 

JFrog Connect provides OTA software updates that support fast deployment and lightweight software updates remotely (using the new method outlined above). 

A smart rollback engine will automatically identify failures and revert devices to the previous software version.

The JFrog Connect platform also provides tools to help manage and support IoT products by giving users the option to connect remotely with a secured connection to any of your products in order to provide technical support. The registration to JFrog Connect is completely free and even includes an example device to let you play with the platform. 

Another great advantage of JFrog Connect is the super simple and fast integration with any Linux-based device which takes no more than 1 minute and is possible to be done with already deployed products in the field too.

How to deploy a remote software update using JFrog Connect?

Now that you understand the best methods for updating embedded Linux devices, at JFrog Connect there are two tools available that will quickly and remotely deploy OTA software updates with ease.

JFrog Connect Micro update tool 

If you’re looking for an all-in-one smart system, this update tool will deploy and manage OTA software updates with ease. Designed to support remote embedded Linux-based products in any environment and scale.
It can be used on robots, kiosk screens, gateways, machines, city cameras, and much more.
It’s easy to use and can be used to deploy files, directories, and packages in seconds. It comes with the following mechanisms built-in:

1. Smart Rollback. As outlined throughout this guide, smart rollback is important to have in any OTA update tool. If a deployment update fails on a Linux device out in the field, the rollback system is responsible for reverting the deployment and ensuring the device is secure and stable for use automatically.
2. Smart Replacement. The micro update tool automatically replaces deployed files and directories that have similar file names on the same path. This is a great feature if you want to upgrade your current product software app without having to remove it first.
3. Deploy Design. A lot of thought and care has been taken to ensure that the micro update tool provides a safe and stable environment. This is achieved by filling a recipe of the deployment, ensuring your app isn’t damaged during the upgrade process.
4. Security. The micro update tool has a diligent architecture. It’s been built and designed to match healthcare and enterprise compliance: end-to-end ASE256 encryption under AWS-based architecture.

JFrog Connect Container Update tool

This is an all-in-one system that allows you to deploy and manage OTA Containers updates on remote embedded Linux-based products no matter what environment and scale they are in. It’s ideal for agile software solutions.
The ideal use case for the container update tool is for those who run the product software application in Docker containers.
Here are some of the mechanisms included:

1. Docker Hub & AWS ECR Integration. The JFrog Connect container update integrates seamlessly to Docker Hub and AWS ECR. This ensures smooth, easy-to-use, secure deployments. Containers stay at DockerHub and are deployed directly from your repository to the edge device.
2. Smart Rollback. Just like the micro update tool, there is a rollback feature in the container update tool that will revert deployment and bring back the old container to work should there be any failures.
3. Scale & Fit. The JFrog Connect container tool comes with all the options that Docker built. It enables the deployment of containers multiple times with different flags and options directly from JFrog Connect, remotely.

You’ll find JFrog Connect update tools being used all over the world. Join our ecosystem today and ensure a smooth and easy production season.

It takes 60 seconds to register, connect a device, and start deploying remote updates.

Register —> https://connect.jfrog.io/