Updating software or firmware of a machine or plant is a complex task and different devices have different requirements to the update or installation of software. To support this, the SoftwareUpdateType provides several options where a vendor can select the parts that are necessary for the software update.

All these options are exposed as optional References of the SoftwareUpdateType. A Server can choose which options it wants to support (the Profiles section describes valid combinations of options).

This way the Server can choose between Direct-Loading, Cached-Loading or FileSystem based Loading and it can use additional optional features like manual power cycle, parameter backup / restore or confirmation.

It is necessary that a Software Update Client checks which options are exposed by the Server and how the Server behaves during the update (a Software Update Client is described in 8.3.5).

There are situations where it is preferable to prepare the device explicitly before the installation and resume operation explicitly after the installation. The PrepareForUpdateStateMachine, which is described in 8.4.7.9 can be used for this task.

This can be the case, when several devices of a machine should be updated at once. All devices have to be prepared first to ensure that all are waiting for an update. After that they can be updated by the Client. At the end after all individual updates are complete the devices can resume operation.

Or a device requires the behavior to enter a safe state (e.g., reaching a safe area) to be able to update the software.

If the installation comprises several steps (e.g., backup parameters, install firmware, restore parameters). The steps can be encapsulated by the Prepare and Resume Methods to ensure consistency between all the steps.

The Direct-Loading option provides a model where the installation is part of the transfer. To support the Direct-Loading model the Server has to provide the Current Version. This includes parameters like the version number, a release date or patch identifiers. With this information the Client can decide if an update is required and which version to install.

The Software Package is transferred using the TemporaryFileTransferType (OPC 10000-5). This includes the installation itself so that the installation option is not used.

Note that if the Software Package is installed during the transfer, the server cannot verify the integrity of the complete Software Package before the installation. If this is required, Cached-Loading is a better alternative.

For Direct-Loading the DirectLoadingType is used, which is described in 8.4.4.

The Cached-Loading option provides a model where the transfer of the Software Package and its installation are separate steps. To support the Cached-Loading model the Server has to provide the Current Version and the Pending Version. Optionally the Fallback Version can be supported.

With the Current Version the Client can decide if an update is required and which version to transfer. With the Pending Version the Client can ensure to install the desired version after the transfer of the Software Package. With the Fallback Version the Client can install an alternative version.

Software Packages are transferred using the TemporaryFileTransferType (OPC 10000-5). The new software can be transferred in the background without stopping the device. The actual installation of the software can be done later using the installation option.

Note: This loading option is the preferred option for best interoperability between Software Update Clients and Devices.

For Cached-Loading the CachedLoadingType is used, which is described in 8.4.5.

The Cached-Loading option with a self-contained Software Package and concrete definition of the version information can be too restrictive for some devices. E.g., if new software should be installed. For this use case the FileSystem based Loading provides an open structure of files and directories where a Client can read and write. These files could be e.g., configuration, setup files or recipes.

Note: The FileSystem exposed in the AddressSpace is not necessarily congruent with the actual file system of the device.

Note: Since FileSystem based Loading supports adding new software and updating multiple parts with individual versions, there is no standard way to expose the current version number(s) of the system. Therefore, a Software Update Client requires additional vendor-specific information, or other companion specifications must define a more specific use. If the additional flexibility of FileSystem based Loading is not required, Cached-Loading should be preferred.

The purpose of the directories and files is not part of this specification. It is necessary, that Client and the Server know it. Other companion specifications could add this definition for specific types of devices. If accessed by a Software Update Client, the FileSystem root can be used to store and install the files.

For FileSystem based Loading the FileSystemLoadingType is used, which is described in 8.4.6.

Using the Cached-Loading option or the FileSystem option, a transferred Software Package or file is installed explicitly (compared to the implicit installation of Direct-Loading). Therefore, the InstallationStateMachineType shall be used (see 8.4.9). It can either be used to install a Software Package (Cached-Loading) or a list of files from the FileSystem (File System based Loading).

The update Clients are often operated by human users. Since an update normally is a long process, the user would like to see the current state. At a first glance the percentage can give a hint about completion of the update, especially if several devices are updated at the same time. But if there are unexpected delays or errors the user requies a detailed textual description about the current update action or issue.

This can be accomplished with the UpdateStatus Variable (see 8.4.1.8). A Client can subscribe to it for a user display. At least if a state machine is in an error state the UpdateStatus should provide a meaningful error message for the user.

If the device cannot keep the parameters during the update, it shall support the Parameters Object of the SoftwareVersionType (see 8.4.1.7). If supported by the Server, the update Client should perform a backup of the parameters before and restore the parameters after the software update.

The confirmation option supports the use case of 8.2.2.9: A Client can set a ConfirmationTimeout before the installation. After every reboot of the Server caused by the update, it shall wait this time for a call to the Confirm Method. If the call is not received the Server shall perform a rollback to enable a working Client – Server connection again. This state machine is defined in 8.4.11.

The power cycle option is intended for devices where a manual power cycle is required. During the installation the state WaitingForPowerCycle informs the user that it is time to turn the power off and on again. The PowerCycleStateMachineType is defined in 8.4.10.

If an instance of the SoftwareUpdateType supports the power cycle option, the UpdateBehavior RequiresPowerCycle shall indicate if this can happen for an installation.

This power cycle state machine is used in combination with the installation. For Cached-Loading it can be used in the Installing state of the InstallationStateMachineType. For Direct-Loading it can be used during the transfer of the new software with the TemporaryFileTransferType (OPC 10000-5) of the DirectLoadingType.