Definition
OTA (Over-The-Air) refers to remotely updating device firmware or configurations via a wireless network without on-site operation. Firmware OTA is also called FOTA, and configuration delivery complements OTA to enable remote device operations.
Core Capabilities
- Full/Differential: Full Package and Delta Package support different upgrade scenarios
- Gray Release: Gray Release performs small-batch verification before full-scale deployment
- Rollback Protection: Rollback and A/B Partition ensure upgrade safety
Firmware OTA and Configuration OTA
FOTA firmware over-the-air upgrade is used to update device operating systems or application firmware; configuration OTA is used to deliver parameters, certificates, scripts, etc., usually through Device Shadow or Downstream Command. They complement each other to form complete remote operation capabilities.
Integration with CI/CD
OTA can be integrated with CI/CD pipelines: code submission triggers a build, after passing tests the firmware is automatically uploaded to the platform, an OTA task is created and a Changelog is generated. It supports scheduled upgrades within Maintenance Window to minimize impact on business. The platform needs to record upgrade progress, success rate, and failure reasons, and supports retry and Rollback strategies.
Remote update covers both the image and the configuration
In device management, over-the-air update is the name for a set of remote changes. It can replace the firmware image the boot depends on, and it can also deliver parameters, certificates, or scripts. Neither kind of change requires shipping the device back to the line, but the cost of failure is not the same. A failed image can leave the device unable to connect again. A failed configuration is more often a function that behaves wrongly, and the device can often still connect and be changed once more. The task model should therefore separate the kind of change, the versions and hardware it applies to, and what counts as finished. Finished means at least this: the content arrived, the integrity check passed, the device has switched to the new content, and it can report the new state back. Putting a file at a download address on the platform is not an update completed. If a configuration change is delivered as a desired value, the actual value should be readable and compared. When the read-back does not match, the task should stay unconverged, not be marked successful. An image change needs its own version field. The two paths can appear in one release, but the order has to be stated, so a new configuration does not arrive while the old image does not yet understand those fields. Firmware signature mainly constrains images and critical packages. MQTT often only carries "you may start" and the progress to the device.
When remote work can replace a site visit
Remote update can replace a site visit when the device still has a usable management channel, storage and power can carry this change, and there is a way back that does not depend on the new version. The way back can be an old partition, an old configuration that was saved, or a recovery image that can still connect. Work that must not be interrupted should be postponed. The target content has to match the hardware and the current version. A mismatch should be refused before download. The operation has to stay in the audit: who, which batch of devices, when, and which revision was delivered. A bulk task should be pausable, and it should report devices not yet started, in progress, and failed, rather than one overall progress bar. The maintenance period, widening in batches, and the rollback policy are constraints on the task, not notes added afterward. If a device stays offline for a long time, the task needs an expiry, so it does not wake months later and apply a change that is already out of date.
Treating task success and service availability as the same thing
Download progress ending is recorded as success, while the device has not rebooted, or it rebooted and is still running the old version. A configuration write succeeds but the application does not reload it, so the desired value the platform reads and the device's actual behavior disagree. The new version can report a heartbeat, a critical peripheral fails to initialize, the service is already unusable, and the statistics still say everything succeeded. A rollback that only changes the target version on the platform, and does not actually send the old content back to the device, does not roll anything back. Two tasks changing the same set of parameters at once both record success, while the later write covers the earlier one. Failed devices removed from the denominator make the success rate count only those still online and not reporting an error. A signature failure that is allowed to be skipped still advances the task state. A device that comes online only after the task has closed, and then runs the old task, applies a change with no window and no approval. Using the disappearance of a business alarm in place of a version check looks like the upgrade "cured" the fault when the alarm rule was simply relaxed in this release. Before a task is closed, check the actual version or the actual parameters reported by one device. Do not look only at the summary progress.