If it's a Raspberry Pi, Nvidia Jetson Nano/Xavier, Variscite's SOMs, BeagleBone, or any other IoT, embedded Linux based device, this post will take you through the best methods to deploy OTA updates in purpose to keep the remote product fleet updated, stable, and secured.
Time to read:
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.
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:
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
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:
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:
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:
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:
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 (formerly Upswift). JFrog Connect's platform provides a management dashboard for IoT and connected devices.
JFrog Connect (formerly Upswift) 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 (formerly Upswift) 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.
Now that you understand the best methods for updating embedded Linux devices, at JFrog Connect (formerly Upswift) there are two tools available that will quickly and remotely deploy OTA software updates with ease.
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:
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:
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/register/