Connected devices have become part of people’s everyday lives. From smartwatches to medical sensors and fitness trackers, we now have all sorts of tech that helps us with mundane tasks, or simply increases our well-being.
And because those devices are integral to people’s routines, performing updates becomes a bit tricky; getting them wrong can lead to a massive drop in ROI, and not giving them any thought from the moment you start building your device is a recipe for disaster.
This is why in this article, we’ll explore how to implement over-the-air (OTA) updates for connected devices without impeding UX and performance. We’ll go through:
The definition and importance of OTA updates;
Things to keep in mind when setting them up;
OTA updates best practices.
Let’s get started!
What are OTA updates?
OTA updates make it possible for a device to be updated remotely. They exist so that companies won’t need to recall the devices anytime a new software version is introduced and the users can enjoy the latest versions without any hassles.
There are no rules in terms of how often those updates are performed, and how much data is actually updated. Some devices will need weekly updates, while others can go months without any improvements. What matters here is making the update the least inconvenient for the user.
Why are OTA updates so important?
OTA updates can make or break your device, and that’s not even an exaggeration.
If you don’t start the development of your device with OTA updates in mind, you’re left with no way to upgrade it unless you recall it from the customer.
As your product grows, it’s inevitable that it will need some improvements. Without OTA, your clients will miss crucial security updates, improvements to user experience, and – what’s maybe the most important – bug fixes.
Intent, Being a software development company, knows the significance of OTA updates firsthand. We have worked with clients who have seen a huge spike in the return rate of their devices because of updates not coming through as they should. It happens because customers get frustrated that there is no way of updating the device , so they return it.
This is where the importance of OTA updates lies: it’s what makes the difference between a potentially buggy mess and a fully functional device that your customers can enjoy.
What to keep in mind when setting up OTA updates
I’ve mentioned how OTA updates, while being essential, can be tricky to perform. Let's go through the most critical aspects of the process, and how to make the updates both secure and convenient for the users.
Security
Making your device safe is probably the most crucial part, as the firmware can be a victim of hacking attacks where your code and personal data can get stolen.
While a lot of developers would rather make their own OTA process, for security’s sake, I believe it’s better to use something standardized. The DFU method, i.e ’Direct Firmware Update’, is the best in that regard. It is popular among programmers, so a lot of issues get solved by developer communities.
You can, of course, use your own solutions, but the reason standardized communication protocols and encryption methods are a safer bet is that they’ve already been tested out by the community (like, for example, the SSL method). Custom-made methods can’t give you that assurance, and they are more likely to have security vulnerabilities.
How to ensure a DFU is secure?
A DFU is made possible by a piece of code – a so-called bootloader, which enables you to erase the previous version and save the new version on the same memory.
Ninety-nine percent of the time the device runs the main code. However, during an update, the microcontroller jumps to the bootloader, which is just a safe firmware that can’t be changed. For safety reasons, you have to ensure that the bootloader is tested and as simple as possible.
One important thing to keep in mind here is the place where you keep your encryption keys. They should be left out of bootloaders, because if someone was to break the keys, it would not be possible for you to change them. Hackers can try to do this in order to replace your code, or just to prove they can.
I really can’t stress this enough: keep your encryption keys out of bootloaders!
Battery vs CPU
The challenge with OTA updates when it comes to connected devices, such as the Oura ring we developed here at Intent, is that we’re dealing with a very small battery inside the device, which is responsible for its every function.
We have a certain amount of power and a certain amount of CPU that we can use, which results in a sort of trade-off between CPU and battery.
If a part of the battery power is, for example, used to power the sensors, then the amount of CPU used needs to be lowered: the more sensing the device can do, the less processing it can do.
The computation for an OTA update should be as low as it can be, giving the user as much battery power as possible to do everything else on the device. If the updates and computation are using up all the battery power, the device won’t run for very long, and there will be limitations to how many tasks the device can perform at once.
Beware of overly complicated methods to update the device. Also, pay attention to encryption methods when you have a limited power source. Some methods (mainly asymmetric) drain more power than others.
User behavior
Being aware of how users interact with the device is far more important than you might initially think. Here, I’m going to talk about the two most important issues to be mindful of: managing unfinished updates and downgrading firmware.
Unfinished updates
Here’s a very likely scenario: imagine you’re starting the update, but the owner turns off their mobile phone. How should you proceed?
You need to decide whether you want to restart the update when they get back or continue from the point the update got to. The second option is obviously the preferable one; splitting the firmware into chunks of code so that the update can restart from a specific point is an important part of good UX.
Downgrading firmware
When you’re releasing the next firmware version, you need to take into account that users might want to downgrade to the previous one. It does happen – your customers may want to go back to the last version for various reasons, like because of a missing feature in the new one, for example.
Downgrading may be dangerous if not handled properly. You need to decide if you want to allow the user to perform such an action, as a downgrade might change the structure of the data and cause damage.
If you develop your code in a way that uses standardized structures like a database or XML, a downgrade shouldn’t cause any issues. The code will just ask the database for some specific settings and retrieve them.
Remember: you need to decide whether you allow the user to downgrade at the very beginning of developing a firmware update!
OTA updates best practices
Manage potential issues
Do your research: think in advance about anything the users may do with the device, and how they use it. Learn how they will usually perform the updates, and where will they likely be when starting them up. Knowing how your customers interact with the device is crucial for making sure that the update goes on smoothly.
TESLA is a good example of OTA updates done right in that regard. The update is started when there are no people in the car, and the AI chooses the time you’re least likely to use it.
Inform about the progress
This is a massive factor for good user experience, and one that can easily go under the radar when you're developing the device.
Informing the users about the progress of the update is an absolute must. Above else, avoid a scenario when your customer presses a button and is suddenly left without any feedback.
Create a simple progress bar – something that lets the user know what’s going on, and don’t rely on inaccurate timers as that will only irritate your clients.
Be mindful of energy consumption
I can’t stress enough how important managing the energy is when performing an OTA update, especially when we’re dealing with small devices. Be mindful of the limitations, and make sure to maintain the amount of energy needed for the device's security without damaging the performance.
Specialized software development companies are experts when it comes to BLE optimization and can help you figure this out – it’s something we do regularly for our clients here at Intent.
Speed things up
Time is crucial when it comes to OTA updates. Some may even take two hours, which is way too much time if you’re planning to update with the user present.
When they’re likely to use the device, updates should take around 5 to 10 minutes at most. If you’re planning for a longer update, it needs to be planned when the user is asleep or unlikely to use the device.
Summary
OTA updates are there to make things easier for the clients and ensure they don’t miss any crucial improvements to the device.
When setting up the OTA process, think of managing things security, energy use, and user behavior, so that your customers can enjoy the device to the fullest. If you research your audience, plan the timing, and manage potential issues from the very beginning, you can be sure that your OTA updates will pass through smoothly.
Need recommendations on how to handle OTA updates for your device? Leave us a message!
Przemysław Łagód
Head of Hardware
