SoftwareUpdatable and constrained devices
Sidekick service and the Custom Protocol Gateway
The main concept of the SoftwareUpdatable (SUP) feature and its default implementation is built on a command-response pattern, namely:
Device comes online, i.e. the built-in ConnectionStatus feature reports an online-window to the device connectivity layer and the digital twin layer.
Device receives the command to initiate an update ("install").
Device downloads and reports success or failure.
Constrained devices do not stay online even for brief periods of time - and therefore the install command does not have enough time to be executed. Such a constrained device usually sends a single GET request (when using HTTP) and expects in response all required information needed to proceed, e.g. configuration changes such as poll frequency. When there is a software update in place - all download-related information.
There are cases when a "driver" connecting such a device may hold back the response for a certain period of time, in order to check if an install command will be fired. This is not considered to be a good practice, as the device is artificially held online thus using valuable GSM resources.
Instead, we recommend adding a sidekick service to the digital twin layer, which receives the commands all the time, and fills a local cache for preparing the next response to the device.
Within a campaign in the software update layer the install command is sent to the digital twin layer.
The install command can be received by a sidekick service even though the device is not online.
The command is not sent to the protocol gateway, as it would only be sent when the device connectivity layer recognizes the device as online.
The sidekick service can translate the received information and store it in a custom format back in the thing (or in its own DB).
When the device does its periodical poll, the protocol gateway can query the aggregated information from the thing and give all information in the response of the poll back to the device.
The device can now either download via HTTP/HTTPs from the software update layer or the protocol gateway can decide to provide a custom way of downloading the artifacts, e.g. via UDP binary streams.
Using different protocols for artifact download other than HTTPS
Initially, the software update layer CDN supports only HTTPS artifact download (with support for RFC7233 range requests).
In order to use different transfer protocols there are still the following options:
Setup a protocol proxy and an artifact cache. Even when the URLs are different, the referenced artifacts can be uniquely identified via name and checksum. A sidekick service may download (and even cache) artifacts using HTTPS and then expose different URLs (e.g. FTP) to the device.
This proxy could become a bottleneck in cases when there are many devices requesting downloads.
Using the software update layer artifact storing and URL generation mechanisms could be totally avoided when the information about the artifact location (e.g. ftp://...., docker-image-name) is put into the meta-data of a software module. This way the software update layer is used only for orchestration of the process and does not take part in securing the downloads.
Get into contact with the software update layer support team and discuss if it makes sense and if it is possible to support the desired protocol out-of the box.
It is better to refrain from using the side-kick service for proxying/routing the downloaded artifact through the digital twin layer, as this would put a very high load on the overall communication infrastructure!
Protocol proxy: Using an artifact cache and dealing with expiration of URLs
In cases when there is a protocol proxy in place which translates an HTTPS download into another streaming protocol, it makes sense to have an artifact cache in place for the currently assigned artifacts.
Usually the URLs for downloading from the software update layer are valid for 30 days (after that period a device is not capable to download the artifact anymore) so if the device needs more than 30 days the assignment will fail.
The use of a protocol proxy offers the following options to bypass this behavior:
Option 2: Re-trigger the install command with the online event
The sidekick service receives the install command at the moment when the install command rule is created within the mass management layer.
The respective thing state is updated and marked as pending install commands.
At the moment when the constrained device does its poll, the Custom Protocol Gateway just signals that there is a pending installation (maybe artifact name and checksum but no download URLs, just that the device should establish a connection).
The Custom Protocol Gateway sends a deviceOnline event via device connectivity layer to the digital twin layer, which will cause the install command to be fired.
The install command will now contain valid URLs (30 days) which can be used by the C ustom Protocol Gateway to download the artifacts for the actual running installation.
Considerations :
There could be some delay where the C ustom Protocol Gateway must keep up the device connection until the first artifact is downloaded from the software update layer CDN - nevertheless downloads from the CDN should be very fast.
A local cache could be implemented to speed up even further - an evict strategy can be freely chosen.
No upfront cache.
Note that the install command is configured as "once-per device", meaning that a second deviceOnline event will not re-trigger the install command again.
Option 3: Increase the validity of the CDN URLs
The validity of the URLs can be increased e.g. to one year.
Please make sure that a spoofed URL cannot be misused and the artifact installer on the device uses additional validation and encryption mechanisms. I case of a misuse (e.g. massive downloads - not coming from devices) it might be needed to remove the artifact from the CDN.