Over-The-Air software updates—OTA—are a method of delivering updated software or firmware to remote devices using a wireless connection. A new version of the software is built and uploaded to an update server, and then it is fed to the respective devices.
There are numerous challenges to keeping IoT (Internet of Things) devices updated and patched, particularly when those devices are remotely located. Failure to properly maintain devices can result in hacks and data breaches, thereby increasing the pressure on IT departments.
The simplest way to update these devices is to do an Over-The-Air software update. But the infrastructure required to enable OTA software updates is enormous, and devices need to be properly programmed to communicate with the update server. That’s why businesses usually outsource their Over-The-Air software update needs to a company that has the infrastructure in place, such as emteria.
IT costs can be high for manual updates. Investing in Over-The-Air software updates that make it better over time is the way to solve this. IT teams don’t need to be deployed to carry out manual updates. And devices can be easily given the latest features, giving businesses a competitive edge.
Most importantly, security flaws can be quickly patched without having to wait. The penalties for data breaches alone could cripple many businesses, and having a proper Over-The-Air software update solution is the surest way to avoid these.
There are two primary methods of carrying out an Over-The-Air software update:
Manual OTA software updates
Automatic OTA software updates
Manual Over-The-Air software updates require the end-user to take some action on the device to confirm the update. This is the most common update procedure used for consumer mobile phones.
In a manual Over-The-Air software update, the device is either initially configured to regularly check for updates, or the user must explicitly click on a link to check for updates.
By running this type of Over-The-Air software update, the device’s firmware is updated, or new software features are installed.
Manual Over-The-Air software updates don’t require an MDM service (Mobile Device Management) to execute the update. They are executed on all configured devices as soon as the Over-The-Air software update is available.
In truth, a manual Over-The-Air software update is only manual from the user’s perspective. At an infrastructure level, building the software and uploading it to the update server still happens automatically.
For emteria’s version of Android for embedded devices, there are two items that must be configured on each recipient device for a successful manual Over-The-Air software update:
The release channel (nightly, beta, or live releases)
The update schedule
Emteria provides Nightly, Beta, and Live channels. Actively used devices that are in operation should be configured to receive only Live builds. These are thoroughly tested builds and will ensure that the Over-The-Air software update does not cause the device to fail.
Devices that are used for test builds should be configured to receive beta or nightly builds only, depending on where in the testing phase those devices fit.
Updates can also happen at a certain time of the day without the user needing to approve the update. In this case, it isn’t a manual update, but still fits in the category of OTA software updates that are not being controlled remotely via a device management console such as emteria's Device Hub.
One example would be to run this Over-The-Air software update only at night. This ensures that these OTA software updates do not conflict with business operations.
More information about scheduling Over-The-Air software updates with emteria can be found on our update scheduling page.
Automatic Over-The-Air software updates are best suited to devices that don’t have a user operating them, such as the plethora of IoT devices in the world. The update is controlled via an MDM hub, such as emteria’s Device Hub.
In this case, no user interaction is required for the Over-The-Air software update. The fleet manager sends a command to update a subset of devices (or all of them), and the update is carried out entirely automatically. The fleet manager has full control over what happens to the device, including updating settings, apps, and so on.
Unlike updates that happen on a schedule, or when the user approves, the device is fully controlled by an admin in automatic (remote) Over-The-Air software updates. No end-user interaction is required whatsoever. The schedule of the update is determined entirely by the fleet manager.
It is aptly called an “automatic update” because the device doesn’t require the slightest bit of human interaction to change anything at all on it.
Any type of update can be sent over the air, whether this is an updated app, operating system, or the firmware itself. In other words, the phrases “Over-The-Air firmware updates” and “software updates IoT” are almost interchangeable because OTA software updates can handle either type.
When carrying out remote IoT Over-The-Air software updates, a fleet manager can decide precisely which type of update to execute, and to which devices.
Android on Raspberry Pi is an extremely popular choice for IoT devices, and one of the easiest ways to enable Raspberry Pi fleet management is to connect those devices up to emteria’s Device Hub. Once each device is connected, Over-The-Air software updates can be carried out easily.
The reason Over-The-Air software updates are so difficult for non-specialist businesses is that there are some important pitfalls to consider when carrying out Over-The-Air software updates.
If an Over-The-Air software update fails, the device can be rendered unusable, requiring manual intervention by a technician to resolve it. Depending on the location of the device, this can end up being a costly error. If it occurs on multiple devices, it can have an enormous impact on a company’s ability to function.
The solution to this type of Over-The-Air software update failure is multi-pronged:
The first is to build a robust Over-The-Air software update infrastructure in the first place. This spans hardware, software, testing, automatic builds, and a dedicated team to regularly monitor it all. The solution must also include failsafe methods to verify that an update has been carried out successfully. If it hasn’t, then there should be a rollback method to return the device to its previous state.
There should also be extensive testing carried out on beta devices before feeding updates to live devices.
Finally, using emteria’s Device Hub, it is possible to send an update to only a subset of devices, or even to only a single device. By running the Over-The-Air software update on a single device, one can rest assured that the update really does work, then send it to a subset of devices, and finally to all of them.
If not properly secured, the transmission of the update from the server to the device could theoretically be intercepted, and a malicious version of the software injected into the transport path.
Solution: Industry standards must be implemented regarding secure communication between the device and the update server. This type of attack is truly advanced and yet foiling it only requires the simplest of practices, such as sending the information across an encrypted channel, and having verification procedures at both the receipt and origination point.
There should also be code in place to check the code signature of any update received.
Emteria has implemented each of these points rigorously in its Over-The-Air software update procedures.
There are several aspects to carrying out OTA software updates in a way that ensures their success.
In a full image update, the entire update must be installed at once, or not installed at all. This prevents partial installations.
These OTA software updates are much smaller. They usually only contain tiny binary patches for software that is already on the device. Because they do not affect the entire device, errors can be fixed quickly in the rare case that the update has bugs.
In these Over-The-Air software updates, the target device has two partitions called slots. The update is installed to the second slot and the previous slot maintains the earlier version. If the update has errors, one can immediately revert back to the first slot.
Because the A/B system update gets installed on a second slot, the first slot can continue operating while the new version is installed in the background. This ensures no downtime except the time it takes to reboot the device into the new slot.
The system only switches to the new version once it has verified that the update was successful.
One of the biggest challenges of creating a one-size-fits-all embedded system for IoT is that there are so many different hardware configurations around. This was indeed the primary reason we created emteria.OS in the first place—there wasn’t enough support around for an Android version that could be installed on almost any hardware setup.
Ensuring that your Over-The-Air software update supports the hardware it is going to be installed on is crucial to ensuring the success of the update.
Finally, the update must be verified. If it has not been successful, then it must be automatically rolled back.
The verification process carries out a number of checks (such as booting and running certain applications). Only if all of them work is the update considered successful.
Emteria developed its Device Hub to be both intuitive and user-friendly. Its functionality offers extreme flexibility in MDM for small businesses and large businesses alike.
Using the Device Hub, fleet managers can carry out minute changes per device, such as setting the correct screen rotation, to full-blown Over-The-Air software and firmware updates. And they can do it on just a subset of devices at first to ensure the update runs correctly, then on all devices.
Powering this feature of the Device Hub is the immense infrastructure that emteria has built behind it, to ensure that Over-The-Air software updates always run smoothly.