OTA with rollback: updating a fleet without travelling
What a two-partition update guarantees and what still depends on the project: infrastructure, planning and validation.
What a remote update with rollback is
A remote (over-the-air, OTA) update sends the new firmware to the device over its network and applies it without a physical visit. With rollback, if the device fails to boot correctly with the new version, it returns to the previous one by itself. The AITHA Core electronics base supports this update with A/B partitions and automatic rollback.
An A/B update keeps two firmware copies. The new version is written to the inactive partition while the device keeps running the active one; on reboot the bootloader switches to the new partition and, if it boots and passes validation, it is accepted. If validation fails, the previous partition becomes active again.
What it offers the operator
- Fewer site visits: firmware arrives through the device’s own connectivity.
- Reduced risk: a failing version does not leave the device unusable; it reverts.
- Traceability: a fleet can be updated in staged batches and verified after each one.
What it does not guarantee by itself
Automatic rollback returns the system to a known previous state, but it does not replace deployment planning: test the version on a small sample, stage the batches by groups, verify connectivity and anticipate interruptions. It also does not replace operator support when an update exposes an environment issue.
Updates in practice
In an implementation using the AITHA Core technical datasheet, the project defines: distribution channel, schedule, validation criteria and the procedure when a batch does not confirm a correct boot. Actual over-the-air availability depends on connectivity and on the product configuration in each deployment.
What the AITHA Core technical datasheet documents
The AITHA Core technical datasheet documents remote updates within the multi-network connectivity of the Cat-1 LTE modem and Wi-Fi: the inactive partition receives the image while the active one keeps operating, and the bootloader decides which one runs at the next reboot. The process depends on the device connectivity being operational and on the firmware distribution channel defined per project.
It also documents the mechanisms that support updates: a watchdog supervising the system and critical services, and NVS persistence keeping configuration and state across reboots. The watchdog is what detects a failed boot and triggers the return to the previous partition without intervention; NVS prevents an update from losing the device operational parameters.
Update in batches and verify
Automatic rollback protects the individual device, but a fleet is updated in batches: a small first group validates the new version under real conditions, and expansion is decided from the results. After each batch, devices are checked to confirm boot and connectivity. If a batch fails, distribution is paused, the version is reviewed, and the decision is fix or stay on the previous one. The process does not guarantee that a new version has no issues; it guarantees the decision is made with data.