Updating firmware is easy. But what happens when millions of connected devices need updates at once? Explore how FOTA handles them at scale—without costly service visits.
As connected devices proliferate across industries, organisations need firmware-over-the-air (FOTA) systems that can manage thousands or millions of devices from a single platform. A scalable FOTA architecture lets organisations monitor firmware versions, hardware revisions, and deployment status, while remotely updating devices regardless of the software version currently installed.
FOTA is becoming increasingly important as product development cycles shorten. Companies are launching products faster, often in smaller batches, while customer requirements can change throughout the product lifecycle. Since not every real-world condition can be tested, software bugs can emerge after deployment. FOTA allows organisations to remotely deploy bug fixes, performance improvements, new functionality, and security updates, reducing the need for recalls and on-site maintenance.
FOTA is widely used in sectors with large-scale deployments. Telematics, fleet management, and mobility applications require remote firmware updates because devices are often distributed across large geographical areas. The same applies to EV charging infrastructure. More broadly, IoT devices using Wi-Fi, cellular, Bluetooth, or other communication technologies are increasingly expected to support secure over-the-air updates.
In addition to making maintenance easier, FOTA can extend the lifespan of connected devices. For instance, if a network operator ceases support for a specific technology, devices may become unusable unless they receive a firmware upgrade. Devices compatible with NB-IoT, for example, can be upgraded to support the LTE Cat-M1 network through a FOTA update when an operator phases out NB-IoT networks. This shows that FOTA is no longer simply a way to reduce maintenance costs, it can also be essential to keeping connected products operational throughout their lifecycle.
Device-specific update strategies for scalable FOTA
A scalable FOTA system must support different update strategies based on how devices operate in the field. Broadly, connected devices fall into two categories: always-on devices and battery-powered devices that spend most of their time in sleep mode. Since their operating patterns differ, the firmware delivery method must also differ.
Battery-powered devices wake up in response to an event or on a schedule and communicate with the FOTA server to check for available updates. If an update is available, the device downloads and installs it before returning to sleep mode. This approach is well suited to devices that are not always connected.
On the other hand, always-connected devices do not need to wait for an update from the server. These devices can perform the update at an appropriate time, such as when they are idle or not handling production tasks, preventing unnecessary downtime and disruption in critical operations.
In large-scale deployments involving thousands or even millions of devices, updates must be scheduled so that devices are upgraded only when they are available. This allows the fleet to continue operating while firmware is rolled out in a controlled manner.
The update mechanism also depends on the device architecture. Systems running a full operating system often use delta updates, where only the modified portions of the firmware are transmitted. This reduces download size, saves bandwidth, and speeds up the update process.
Resource-constrained devices, such as microcontrollers based on Arm Cortex-M cores, typically receive a complete firmware image. These devices usually contain a permanent bootloader, while the entire application firmware is replaced during the update. Because the firmware size is relatively small, a full image update is simpler than generating and applying delta patches.
Communication protocols are also selected according to their purpose. MQTT is commonly used for command and control, such as notifying devices that a new firmware version is available. The firmware image itself is typically transferred using HTTPS or FTP, which can handle the reliable delivery of larger files.
| What should you consider to make devices OTA ready? |
| • Plan for rollback from the start. Choose a microcontroller with enough memory to store both the current and new firmware. This allows the device to roll back if an update fails. • Allocate sufficient flash memory. Limited memory can prevent rollback, increasing the risk of device failures after a faulty update. • Build in secure communication. Use secure protocols such as HTTPS/TLS to protect firmware downloads from tampering. • Validate every firmware image. Perform CRC (cyclic redundancy check) before installing the firmware to verify that it has not been corrupted during transfer. Do not skip integrity checks. • Avoid fixed server addresses. Hardcoding the OTA server or IP address can prevent deployed devices from receiving updates if the server changes or becomes unavailable. • Support dynamic server configuration. Allow the OTA server URL or endpoint to be updated remotely so devices can continue receiving firmware updates. |
Reliable firmware storage and recovery mechanisms
Oops! This is an EFY++ article, which means it's our Premium Content. You need to be a Registered User of our website to read its complete content.
Good News: You can register to our website for FREE! REGISTER NOW
Already a registered member? If YES, then simply login to you account below. (TIP: Use 'forgot password' feature and reset and save your new password in your browser, if you forgot the last one!)
