The first task of a Software Update Client is to find the components that support software update. After that it can execute the update of the components one by one or in parallel. The following activity diagrams illustrate how a Software Update Client can perform an update using the different update types. The first task is to detect what options are supported by browsing the references of the SoftwareUpdate AddIn. Then the Client can check the version information to determine whether an update is necessary. This is illustrated in Figure 34.
Figure 34 – Determine the type of update that the Server implements.
The activities of the different loading types are slightly different. With Cached-Loading the Client can check CurrentVersion and PendingVersion Objects to determine if the Software Package is already transferred. With the FileSystem based Loading the Client can browse the FileSystem to find out which files are already transferred. For Cached-Loading and File System based Loading the transfer can be done in advance. There are different ways to get the UpdateBehavior, because for Cached-Loading and File System based Loading this depends on the actual software that should be installed (with Direct-Loading the server has no information about the new software). For Direct-Loading and Cached-Loading the validation is done during the transfer. For File System based Loading this needs to be done before the installation as an extra step. These steps are illustrated in Figure 35.
Figure 35 – Different flows of Direct-Loading, Cached-Loading and FileSystem based Loading
The prepare activity can be handled equal for all types of loading. This optionally includes a backup if the device cannot keep the parameters during update. The activity is shown in Figure 36.
Figure 36 – Prepare and Resume activities
The actual installation of Direct-Loading is done during the transfer. At the end there can be a manual power cycle (option). In some cases (if the Server is on the device that is updated) the Server is rebooted and the Client needs to reconnect to complete the installation. This is illustrated in Figure 37.
Figure 37 – Installation activity for Direct-Loading
For Cached-Loading and File System based Loading the installation is done using the InstallationStateMachineType. For Cached-Loading the InstallSoftwarePackage Method is used and for File System based Loading the InstallFiles Method is used. During this installation there may also be a manual power cycle request requiring operator input. The Client might also need to reconnect one or more times due to automatic reboots. If the Confirmation Object is available, the Client may use it during the installation. This is illustrated in Figure 38.
Figure 38 – Installation activity for Cached-Loading and File System based Loading
The resume activity can be handled equal for all types of loading. This optionally includes restore if the device cannot keep the parameters during update. The activity is shown in Figure 39.
