Updating your device software, whether its system or application level, may seem an easy task to do when you first start your IoT project but then you realize what’s involved is more than just overwriting some files with new copies. What if the power goes out while the device is updating? What if the connectivity is lost due to poor network quality? What if a third party sends a fake update? What if a portion of your devices in the field require updates?
As more of these ‘what if’ scenarios pile up, you’d soon realize that building an end-to-end software update mechanism for connected embedded systems requires more competency than just overwriting some files with new copies!!
At the very least the software update mechanism must be:
One of the most important characteristics of an OTA solution is to ensure the update process is robust. This has many elements to ensure the resiliency of the embedded systems. One of the worst possible scenarios is to have devices remotely deployed and then due to an interruption during an update become unusable and bricked. The resiliency and reliability of the update process should be a central concern given the potential consequences. The key word is atomicity and it requires that in the update process there is no part of the system left behind that is not updated. There must be a single continuous, uninterrupted change to the system software that toggles to the new version of software. There are a few ways to achieve this, one being symmetric image update, or A/B image update.
When designing and implementing an update mechanism you need to have a reliable method to install security patches, new features and fix bugs. However, the same mechanism may be used by others to install unapproved software packages. The biggest weakness is that of a fake remote update and in order to avoid this you need to authenticate the update server before starting to download the software. You will also need a secure transfer channel, such as HTTPS protocol. There is also the authenticity of updates you need to check for and one way is to use a digital signature in the bootloader. If the kernel image is signed at the manufacturing plant with a digital key, the bootloader can check the key before it loads the kernel and refuses so if the keys do not match. Therefore, as long as the keys are kept private by the manufacturer, it will not be possible to load an authorized kernel image.
An update mechanism should have the ability to manage the entire fleet of devices. Many client-only solutions exist. But manual one-by-one updating of devices should be a remnant of the past, even with smaller fleets of just 10 devices. Fleet management requirements can be extensive and have many different requirements depending on the specific scenario and environment. One of the more complicated aspects of an OTA solution is the fleet management capabilities of the management server.
Learn more from a whitepaper on Hidden Costs of Homegrown Updaters.
Download a comprehensive list of OTA requirements checklist here.