I am considering developing on the Yocto project for an embedded Linux project (an industrial application) and I have a few questions for those with experience with embedded Linux in general -- Yocto experience a bonus. Just need to get an idea of what is being commonly done in firmware updates.
I have a few requirements, that being authentication, a secure communications protocol, some type of rollback if the update failed. Also, if there is a way to gradually release the patch across the fleet of devices then that would also be interesting as I want to avoid bricked devices in the field.
How do you deploy updates/patches to field devices today ? and how long did it take to develop it? Are there any other considerations I am missing?
--------------------------------------- Posted through
How much are you planning on updating -- the OS or just the "application(s)"? How "flush" is the device in terms of (spare) resources? Can the application be updated incrementally? Or, is it "all or nothing"? Does the OS/application have to reside on the device, entirely?
What are you trying to protect against? Are you trying to prevent "foreign" binaries from being installed/executed? Or, just trying to ensure that your update is "intact" prior to transfering control to it?
Restating from above: what sort of spare resources do you have (e.g., can you afford to keep an old image *and* a new image on the device until you have verified the new image is intact?)
How painful are bricked devices? I.e., is a bricked device an "annoyance"? Or, can it potentially result in significant (opportunity) costs as the "line" is down for the duration? Can local support staff take measures to remedy this (e.g., keeping a cold spare on hand)?
How are the devices accessed? E.g., are they all "exposed" to some remotely accessible network? Is there a gateway machine that can distribute the updates and supervise their successful installation?
Can all devices update simultaneously? Or, will this impact the production environment (e.g., potentially taking all machines off-line at the same time instead of in a staggered fashion)? Or, do you rely on initial updates as a sense of assurance that the update is "OK"?
If you have multiple *connected* devices in a single location, you could consider serving the binary to the nodes after POST. In this way, you can simplify the "firmware" to just implement a loader and put all of the authentication, administration, VC, etc. on the "server". The advantage of this approach is that you "just" update the server; rebooting (resetting) any of the "devices" causes them to automatically fetch the "appropriate" executable (which may or may not be the most current).
You can define a protocol whereby a device tries to boot a particular image (binary) and is expected to notify the server on successful operation; if not, the device can attempt to boot an *older* version ("known" to work).
[However, you'd typically opt for a RAM-based implementation instead of XIP from Flash, etc.]
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.