redpesk® OTA update system
End to end solution to fully control your partial OTA software updates
redpesk® OTA update system
Key challenge for Over-The-Air update systems is the capability to change only what is required. To do so, the only way is to natively integrate the OTA system since the beginning of the CI/CD process in order to get a real end-to-end traceability of all the changes occured (goal is to establish an update mecanism per transaction).
This is what we achieved with the redpesk® OTA update system as we are able to calculate, test & approve update differentials before sending them. The following diagram highlights how updates are deployed from the CI/CD system :
Our solution is end-to-end solution with all key features : per package-based nature allowing smaller updates and quicker deployment times, full controlled CI/CD process for binary reproducibility, automatic testing (through Rackable Test Module) & various update upload solutions.
OTA update design
In addition to keeping the system up-to-date, one of the main goals for the target updater system is to be as reliable as possible so that no boards end up non-operational because of a failed update. This is achieved using an A’-B design that is:
- a main partition (named B) hosting the full system runtime. While operational, the system always boots on it. Its purpose is to be incrementally updated via RPM updates pushed through the uploader agent. Those packages could be either 'Core OS' ones (i.e targeting the base system) or 'Application level' (for a customer application).
- a recovery partition (named A') which contains a minimal OS albeit fully equipped for a full B partition system restore. This partition is not meant to be frequently updated but can be if needed (for instance if a new WiFi protocol needs to be supported).
The target device partition scheme is laid out as follows to support the above mentioned update mechanism:
redpesk® OTA update system benefits
- secure, reliable, faster and cost-efficient update mechanism via package-based streams
- optimized time-to-market: releases can be done sooner, as more updates can be performed after devices have been deployed
- ability to deliver OTA updates along the entire product lifecycle: engineering, deployment and production
- continuous updates prevent cybersecurity threats
- transactional differentials imply limited test & update traceability per target
