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.
This way the Server can choose between Direct-Loading, Cached-Loading or FileSystem based Loading and it may use additional optional features like manual power cycle, parameter backup / restore or confirmation.
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.8 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 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 decice if an update is required and which version to transfer. With the Pending Version the Client can ensure to install the desired version. With the Fallback Version the Client can install an alternative version.
Software Packages are transferred using the TemporaryFileTransferType (OPC 10000-5). The new software may be transferred in the background without stopping the device. The actual installation of the software can be done later using the installation option.
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 address space may not be congruent with the actual file system of the device.
The purpose of the directories and files is not part of this specification. It needs to be known by the Client and the Server. 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.
Using the Cached-Loading option or the FileSystem option, a transferred Software Package or file needs to be 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 needs a detailed textual description about the current update action or issue.
This can be accomplished with the UpdateStatus Variable (see 220.127.116.11). 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 18.104.22.168). 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 22.214.171.124: A Client may 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.
This power cycle state machine is used in combination with the installation. For Cached-Loading it may be used in the Installing state of the InstallationStateMachineType. For Direct-Loading it may be used during the transfer of the new software with the TemporaryFileTransferType (OPC 10000-5) of the DirectLoadingType.