I need a mechanism to allow for software updates to be
> installed. The (abused) "on-line" approach is unacceptable
> (it forces the device to be "exposed" and makes updates
> too easy (which seems to mean too frequent!).
>
> Pisser is that I need a mechanism that will be supportable
> for 20-30 years. This likely rules out many commodity
> approachs (will we be using NANO-SD cards? PICO-SD cards?
> will USB A/B have given way to C? Or D/E/F?)
>
> If you assume updates are few and far between, the cost
> of the transport medium has little impact on TCO (unlike
> on-line updates which have a big impact on TCO!).
>
> And, if you further assume that the time to perform an
> update is immaterial (because they are infrequent and
> because the system allows updates to happen WHILE it is
> in use -- unlike "reboot to complete your update"),
> then you don't need a fast interface to deliver the new
> content.
>
> So, it seems that a reasonable approach could be a "module"
> that talks to the product using an existing communications
> medium inherent in the product's design (in my case, wired
> or wireless ethernet). The design of the "update device"
> can then change with each update -- so long as the system
> interface remains constant.
>
> A dog slow "processor" that can push packets from some
> storage medium out to the system interface offers lots
> of design opportunities for processing (dedicated logic)
> and storage (media devices).
>
> Because it is active, it can also make note of how and
> when it was "consumed" (should reuse want to be discouraged)
>
> As it's only a one-time use device, there's no need to make it
> serviceable -- discard when done. (no desire to have it
> returned for reuse as it's cost would be a handful of dollars;
> likely less than the price of a first class *stamp*, soon)
>
> Any problems with this approach? Export controls may be an
> issue but I can leave that to someone else to sort out;
> maybe just ignore those markets? (I've had to work in markets
> where you had to smuggle EPROMs through customs...)
>
I wouldn't want to rely on wireless ethernet - there's too much in there that could change over time to the extent that no then available device could talk to it.
Preventing managers from causing on-line update to become available is really difficult as long as software can do updating, since even if on-line update is not implemented from day one, it could be implemented via the last non-online update.
The solution is a device that is physically incapable of updating itself unless some local action is taken, such as pressing a button. As long as no one implements a remote button-pressing device.
Sylvia.