Hello everyone, I am a software upgrade package. In the next few days, I will embark on a magical journey across the internet, from the developer’s computer all the way to the terminal embedded device.
This travel process is called OTA, which stands for online upgrade.
So what exactly is OTA? It stands for: Over the Air Technology, which means downloading a new software package from a server over the internet and updating it to the device.
First, let’s address a question: why is it called a software upgrade package instead of a firmware upgrade package?
In essence, firmware is also software; both are written in code!
Although these two terms are quite similar, some people have made a slight distinction between them in a narrow sense.
Since that’s the case, let’s distinguish them for now:
Firmware: Refers to embedded devices without a file system, where Flash is divided into different functional partitions. The executable program must be placed at a specific starting position to be booted by the bootloader.
Software: Refers to embedded devices with a file system, where the executable program is placed directly in the file system. When the device starts up, the operating system will launch the executable program from the file system.
Embedded devices without a file system:
Devices with a file system:
I know that the above distinction is not very rigorous, but who can clearly define what a rigorous definition is?
For now, let’s differentiate them as long as it doesn’t affect the understanding of the article!
When an embedded device performs a software upgrade, from a macroscopic perspective, it can be divided into 2 stages:
Downloading the upgrade package;
Unpacking the upgrade package and writing it into flash or the file system;
Today, we will primarily focus on the first 1 stage, showing you how I am downloaded step by step from the developer’s computer to the embedded device.
Here’s a complete process for you to preview!
For the sake of description, let’s assume a scenario: there are 3 files in the software running on the device:
Main file: executable program;
config.ini: configuration file;
mylib.so: a dynamic library file containing an algorithm called by the main file;
Currently, the version running on the device is V1.0. The developer has optimized the algorithm in the mylib.so library and upgraded it to V2.0. Now, this new version needs to be upgraded to the embedded device.
The first step is something we can all think of, which is to upload the V2.0 version of the program software to the file server.
Just a reminder: many cloud platforms differentiate between application servers and file servers. Of course, if it’s just for testing, they can coexist on the same physical server.
For example, Amazon’s AWS platform uploads the upgrade package to the S3 server.
Now we need to package the V2.0 version of the program. Besides the main, config.ini, and mylib.so files, we also include another script file upgrade.sh in the package.
The function of this file will be revealed later.
Bingo – the V2.0 version of the upgrade package is born: app_v2_0.tgz, and after uploading to the file server, the address is: http://fileserve/app_v2_0.tgz.
Now that the V2.0 version of the upgrade package has been uploaded to the file server, can we now command the embedded device to download and upgrade?
We know that in an IoT system, there are generally many terminal devices.
These devices may be in a running state or in a powered-off state, and we cannot assume that all devices will upgrade at the same time.
Moreover, once a device has upgraded, it becomes the latest V2.0 version, and it should be able to know that the latest version on the server is V2.0, so it doesn’t need to upgrade again.
Therefore, a new file is needed to describe the V2.0 version of the upgrade package on the file server, which we will call: upgrade package description file app_desc.json, and its content is a json formatted string:
The version field describes the version of the upgrade package on the file server, so the device can know the latest version on the server.
The url field describes the download address of the upgrade package. If the device finds that its version is lower than the version in the version field, it can download the new upgrade package from this address.
The md5 field describes the fingerprint information of the latest upgrade package on the server. After the device downloads the upgrade package from the server, it needs to calculate the MD5 value of the downloaded package and compare it with the value in the md5 field. If they match, it means the downloaded upgrade package is fine and hasn’t been tampered with.
After understanding the role of the upgrade package description file app_desc.json, this file is uploaded to the application server.
At this point, as the upgrade package, I have quietly lain on the file server, and my brother the upgrade package description file app_desc.json is also ready on the application server, just waiting for the embedded device to start the upgrade.
Everything is ready, just waiting for the trigger action to upgrade the embedded device!
So, when and who should tell the device: your running software is too old, and there’s a new version on the server. Please go upgrade!
The answer to this question is: various methods can be employed!
For example:
Amazon’s AWS platform notifies each device that needs upgrading by deploying a job in the cloud platform;
A mobile app can actively send a command to a specific embedded device: Hey, buddy, please upgrade your software;
When the terminal device receives the upgrade command, the first step is to download the upgrade package description.
After downloading, it parses this json formatted text content, extracts the version information, and compares it with the currently running software version.
If the version on the server is newer, it then extracts the download address from the url field and starts downloading the new upgrade package from the file server.
If the current running version is already the latest, then the process ends here!
The process of downloading the upgrade package is simple. You can directly use tools like wget to download, or you can write your own download code using the curl library.
In short, there are countless ways to get me downloaded to the device.
After the download is complete, one very important thing must not be forgotten: check if the downloaded upgrade package is correct!
Remember the md5 field in the upgrade package description file? That’s my fingerprint information.
You need to first calculate the MD5 value of the downloaded upgrade package, and then compare it with the value in the md5 field of the upgrade package description file. If they match perfectly, you can confidently start unpacking and upgrading!
To know what happens next, please stay tuned for the next episode!
Star this public account, to find me faster!
Recommended Reading
【1】C Language Pointers – From Basic Principles to Techniques, Explained Thoroughly with Diagrams and Code 【2】Step-by-Step Analysis – How to Implement Object-Oriented Programming in C 【3】It Turns Out GDB’s Underlying Debugging Principles Are So Simple 【4】Is Inline Assembly So Scary? Read This Article to End It! 【5】They Say Software Architecture Should Be Layered and Modular, How Exactly Should It Be Done?
