|
|
|
# Use Cases for SysOTA
|
|
|
|
|
|
|
|
There are several use cases or deployment scenarios that SysOTA is able to support.
|
|
|
|
|
|
|
|
## Autonomous device without a central operator
|
| ... | ... | @@ -32,4 +30,10 @@ Fleet operator may prefer this approach especially when SysOTA joins a heterogen |
|
|
|
|
|
|
|
Some operators may choose to combine a custom management agent together with NetOTA. This approach leverages SysOTA-specific APIs such as system image packages, update streams and update triggers (to request the update process) to reduce complexity of providing a correct management agent. It is important to point out that this approach still allows the fleet to follow different software configuration builds, versions or stability levels on a per-device basis.
|
|
|
|
|
|
|
|
It is important to point out that even if RAUC is used as the API entry point, SysOTA is still in the loop and provides some additional guarantees, such as data backup and rollback in case of failure. |
|
|
\ No newline at end of file |
|
|
|
It is important to point out that even if RAUC is used as the API entry point, SysOTA is still in the loop and provides some additional guarantees, such as data backup and rollback in case of failure.
|
|
|
|
|
|
|
|
## Local development convenience
|
|
|
|
|
|
|
|
This miniature sub-class is not meant for production but is non-the-less important. With SysOTA, developers can avoid the platform-specific programming/flash process which may require manual interactions and is harder to script. Instead development can begin from a reference BPS image and continuously updated with greater simplicity than a full system re-imaging at every step.
|
|
|
|
|
|
|
|
In this case NetOTA may be used in a greatly reduced form, where the device is configured to pull updates from the developer's workstation or laptop. |
|
|
\ No newline at end of file |
