Besides specific Clients for specific devices, this specification also describes Software Update Clients that can update devices of various vendors (for additional details see 8.3.5).
For Devices in operational use, it is often necessary to consider the operation state of the software / machine / plant before performing the update (e.g. stop and start the operation). For this case a specialized Client can use additional domain-specific Information Models as part of the update process.
An update can be performed manually by a user for a single device. However, if a lot of devices need to be maintained on a regular basis an automatic update is desirable. For this scenario the Information Model also allows the transfer of software to the devices without starting the update process. For the installation a Client could control several devices simultaneously.
This common model can describe several types of software that may need to be updated or installed. This can be the firmware or operating system of a device but also be one or more software applications that need to be updated. Configuration and parameters can be maintained as software as well. Besides the update, it is also desired to install additional software. The Server can expose all software as a single component or separate it into several smaller components as it is illustrated in Figure 33.
Figure 33 – Example with a device and several software components
Devices may have different requirements regarding a firmware update, depending on their type and available resource (e.g., memory).
Memory constraint devices like sensors often cannot store an additional firmware. These devices install the new firmware while it is transferred to the device. In this specification this is called Direct-Loading (see 8.3.4.3).
Devices with more memory can store a new firmware in a separate memory without installing it which is referred as Cached-Loading in this specification (see 8.3.4.4). In this case the installation is separated from the file transfer and can be done later or with a different Client.
Some devices have two memory partitions for the operating system. One active partition that is used in the boot process and a second alternative fallback partition. These devices install the firmware into the fallback partition and then perform a restart after swapping the active partition. This has an advantage if the device detects an issue with the new firmware: The change can easily be reverted to the old version by switching the partitions again (with another reboot).
Constraint devices like sensors typically do not support a real file system. Devices with more memory often have a file system which can be used to store files like firmware, parameters and backups. This Information Model provides update mechanisms for both types of devices (see 8.3.4.5 for FileSystem based Loading).
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 may use additional optional features like manual power cycle, parameter backup / restore or confirmation.
A Software Update Client needs to check 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.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 Software Package is transferred using the TemporaryFileTransferType (OPC 10000-5). This includes the installation itself so that the installation option is not used.
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 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.
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 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.
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 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 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.1.9: 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.
If an instance of the SoftwareUpdateType supports the power cycle option, the UpdateBehavior RequiresPowerCycle shall indicate if this might happen for an installation.
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.
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.
Especially for safety critical devices the update Client needs to inform the user before performing critical activities. This includes the information if a manual power cycle is required, if the device will reboot or if it will lose its parameters during the update. This information can be accessed before the actual update is started. For safety all security considerations also apply.
Security is a critical aspect of software update. The basic requirements can be solved with the existing UA security mechanisms (secure transport, authorization and role-based authentication). Only authorized users shall be able to install and manage updates.
The Client needs to verify the identity of the device. This can be complished by identification information provided by OPC UA, by this specification or by companion specifications.
The authenticity (integrity and source) of the Software Package needs to be verified. These aspects can be implemented by the device in a vendor specific way e.g., verify a digital signature of the Software Package. These mechanisms are out of scope of this specification.
The concrete process of the installation can depend on the device and on the software that is to be installed. Therfore the server provides the UpdateBehavior OptionSet (see 8.5.2). The UpdateBehavior can be determined with the UpdateBehavior Variable (see 8.4.4.3) of the DirectLoadingType or with one of the GetUpdateBehavior Methods of the CachedLoadingType (see 8.4.5.5) or the FileSystemLoadingType (see 8.4.6.3).
Instead of updating the whole software with a new version, sometimes only a part of it needs to be replaced (“patched”). The installation of such a patch can be implemented in the same way as the installation of a complete version. The only difference is that the result is not a new SoftwareRevision but an additional entry in the list of patch-identifiers stored in the PatchIdentifiers Variable (see 8.4.7.5).
If parameters or settings of an old software do not work with the new software, the installation of the new software can complete but the device still cannot start as before. In this case the Server should treat the installation as successful. It can inform the incompatibility using e.g., the IDeviceHealthType Interface (see 4.5.4) of the device / component. This issue can be resolved later by a client that fixes or updates the parameters.
To support an individual software update for the devices of a Server AddressSpace the software update model is defined using the AddIn model as it is described in OPC 10001-7. An instance of SoftwareUpdateType shall be attached to either Objects that implement the Interface IVendorNameplateType (see 4.5.2) or Objects that support an Identification FunctionalGroup (see B.2) that implements IVendorNameplateType. For the AddIn instance the fixed BrowseName “SoftwareUpdate” shall be used. This model gives any device, hardware- or software-component the opportunity to support SoftwareUpdate.
With this mechanism it is also possible to update parts of a software independently: A Server could expose parts as additional software components with their own update AddIn.
To identify the device / component that is the target for the software update, the IVendorNameplateType Interface is used. In this Interface at least the Variables Manufacturer, ManufacturerUri, ProductCode and SoftwareRevision shall be supported and have valid values. Optionally Model and HardwareRevision should be supported. These Properties may be shown to the operator. ManufacturerUri, ProductCode and HardwareRevision should be used to identify the component.
Note that the Properties SoftwareRevision, Manufacturer and ManufacturerUri also appears in the CurrentVersion of the PackageLoadingType. Their values may be different, if the manufacturer of the Device is not the same as the manufacturer of the software. The SoftwareRevision Object shall be the same at both places.
The ComponentType (see 4.6) already implements the Interface IVendorNameplateType. This makes it a good candidate for a SoftwareUpdate AddIn as illustrated in the example in Figure 40.
Figure 40 – Example how to add the SoftwareUpdate AddIn to a component