If you have 1 device or 10 devices, managing these updates still is a pretty easy straight forward job. But imagine you need to do this for 4000 devices or more.

Indeed, that’s right: how do we manage this? That’s the question a lot of people ask and get confronted with.

In case of a limited amount of devices, sending an update to all devices still might look like a good idea. For the 4000 devices everyone understands this might not be the desired mechanism, keeping Werner Vogels statement in mind: design for failure!

Fleet & campaign management

Even if your update succeeded and you have tested it all well, there still might go something wrong with your new version in production.

That is why you do not want to update the 4000 devices at the same time. Instead you want to have multiple campaigns of updates for the same firmware release.

You start with a group of devices and if all works well for these devices, you gradually update all other devices in groups.

Since you want to use campaigns and also want to do it customer by customer or production section by section, … you also want a fleet management in place before you start creating update campaigns.

Scaleability

Make sure your OTA solution is capable of handling the updates of a few devices to hundreds, thousands or even hundreds of thousands of devices.

You might start small, but if your business model works or your management sees the benefit of having updates rolled out at ease, you end up quickly with a large number of devices to update.

And it would be a shame shining in the possibility of remotely updating devices, but failing in upscaling your solution.

OTA levels (config, firmware, app)

A firmware update might seem like a big thing but our remote update might as well be a configuration change of a device. Remote updates are not only applicable to firmware updates. They also apply to new configurations as well.

Code compatibility & verification

Let’s assume your fleet of devices is composed out of multiple MCU architectures. When you distribute firmware updates, it is advisable that your update contains the architecture it is designed for.

So if you receive a firmware designed for an esp32 and the device itself is an ARM32, the device will not update and report the error to the update server.

Emergency updates

In the case of a very high variability risk, you want to roll out an emergency update from the moment it is available. In an emergency situation it might be more important to patch the variability then to have the device check its state context.

Just remember Werner Vogels, … design for failure! If an emergency update mechanism is available you can make use of it if needed. If you do not have it, many devices might be impacted just too long.

This blog is part of our blog series IIoT Intelligent Firmware Updates.

Want to know more?

Get in Touch