As for selecting the right OTA architecture, the one size fits all OTA update mode doesn’t fit anybody. Or does it? It all depends. We’re talking about IIoT, so the answer would be “it does”. For IoT devices in general, it would depend on the use case. But for IIoT devices there is a definitive advantage on using the push-pull mode. For completeness I discuss the other update modes as well, but all remarks mentioned are IIoT in mind and not IoT. 

Push

In this mode, the cloud (or local) update server pushes a new firmware version to each device.

The biggest advantage of this mode is that the updates are immediate. This means that the device is in a state where the update can be applied.

The biggest disadvantage is that this is a very bandwidth consuming mode. Each update needs to be send to each individual device, making it only useful for updating small “fleets” of devices.

Pull

In a pull mode scenario, the device itself checks on a regular basis whether there is an upgrade available and if so, downloads the upgrade.

The advantage of this scenario is that it consumes considerable less bandwidth than the push mode.

The biggest disadvantage is then again the pulling, if the pull interval is long, this might be an issue for critical updates. Then again, if a device is not in a safe state to update it might take long as well before the update is applied.

The second disadvantage is that a device does not need to register for the updates. One might consider that this is an advantage because it is much more simple to develop, but from a device management and security perspective, this is not desired.

Push-pull

In an industrial environment, the best of both worlds, the push-pull OTA mode is the preferred mode.

So if this is the preferred mode why would one bother implementing others? Implementing a push-pull mode OTA requires a much more complex and costly development, so if you are just getting started and only a handful of devices need to be managed and upgraded, a push OTA update might make more sense since the time to market will be faster and the required development budget will be lower.

After all, the OTA process should be able to update itself and switch to a push-pull mode when it receives that update as your number of devices grow (and so will your development budget, making the push-pull OTA mode accountable to your management).

Since this is by far the most important IIoT OTA update mode, the process is described in detail below.

Push-pull process

1. The device connects to the update cloud and registers for updates. The update server is typically a message broker (e.g. an MQTT broker).
2. A new firmware, configuration, application, … is committed on the upgrade server (cloud). This can either be for all devices, a fleet of devices, or a specific device.
3. The new firmware availability for the devices gets stored in a database for audit purposes.
4. A temporary link to the new firmware gets created for each device (only available with the devices certificate) and the link of the update gets pushed on the update broker (where the device registered on).
5. The device receives an event that there is a new firmware version available, together with the temporary link to that firmware version.
6. The device downloads the new firmware over a secure channel. It checks the downloaded update for consistency, decrypts end decompresses it and puts it on the landing zone for new firmware. When this is done, the firmware update server gets informed by the device that the new firmware has been downloaded, so that the temporary link may be removed.
7. When the device is in a safe state it can perform the update. Safe means its context says it is ok to perform the update at that given point in time.
8. The device notifies the update server that the update has been executed.
9. The update server registers the execution of the update in the database for full traceability.

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

Want to know more?

Get in Touch