Firmware-Over-The-Air (FOTA) updates are an essential part of connected devices. FOTA refers to remotely delivering and updating firmware on connected devices. The over-the-air update brings a unique value proposition:
- Faster new feature(s) roll-out
- Quickly address bugs and security vulnerabilities
- Reduce Total Cost of Maintenace to OEM
A key question is: How does one select between a full-fledged OTA system and a simple system that consists of a backend server and REST API invocation from the device? To answer this question, first, we need to understand the key pillars of the OTA system.
Any end-to-end FOTA solution has four essential pillars:- Device, OTA client, Connectivity, and cloud.
Device: Embedded device acting as OTA Gateway
OTA client: Key component responsible in the device for OTA update orchestration and connectivity to the backend
Connectivity: Device connecting over WiFi and Cellular (in rare scenarios where Bluetooth and satellite are considered for download)
Cloud: Overall orchestration of OTA updates for device fleet and intelligent updates
Now, the key question to be asked is, what are the critical attributes of an OTA solution? What should be considered? What are optional and nice-to-have attributes?
Key tenants of any FOTA solution are Reliability, Security, Scale, Built-In deployment strategy, and Easy-to-use.
One should ask a series of relevant questions to understand the nuances of these tenants. The questions below are just food for thought and in no way a complete list for any evaluation:
Reliability:
Q1. Does it provide an atomic update?
Q2. Does it provide full rollback to previous working software?
Q3. Does it follow any well-established spec or proprietary specification?
Security:
Q1. How devices and the cloud authenticate each other
Q2. How robust is Device onboarding to cloud infrastructure
Q3. How payload verified by a device to avoid Man-In-The-Middle (MITM) attack
Q4. How different device versions for hardware types are managed
Q5. Does the client provide enhanced security features such as Payload encryption, signing
Scale:
Q1. Can the FOTA solution scale for evolving IoT deployments (i.e., every device connecting to the cloud connects to a device connecting to the hub (gateway), and the hub connects to the backend, etc.)?
Q2. Whether deployments are localized or global in nature
Q3. Whether the number of updates is frequent or occasional, along with payload size (i.e., in KiloBytes or MegaBytes or GigaBytes)
Q4. How’s the device (or gateway) connected to the backend: always, regular or intermittent
Q5. How are User consents managed along with the GDPR consent
Built-In Deployment Strategy:
Q1. How OEM can perform development, then alpha, beta testing, and finally, large deployments
Q2. How efficient is region-wise deployment?
Easy-to-Use:
Q1. Do you need a dedicated workforce to orchestrate or just a few button clicks (or automation) to run the show
Q2. Does it provide REST API for integration and an intuitive interface to operate?
There is no one-size-fits-all solution. One cannot choose a full-fledged solution for a proof-of-concept; similarly, a simple backend server and REST API invocation from a device wouldn’t work for complex deployments. The production solution architect must consider program objectives, organization security goals, and customer-evolving requirements.
Disclaimer:
This is my opinion based on my experience with millions of OTA events and several deployments in the last ten years. It in no way represents any organization or its strategy.