Besides specific Clientsfor specific devices, this specification also describes Software Update Clientsthat can update devices of various vendors (for additional details see 8.3.5).

For Devicesin 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 Clientcan use additional domain-specific Information Modelsas 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 Modelalso allows the transfer of software to the devices without starting the update process. For the installation a Clientcould 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 Servercan expose all software as a single component or separate it into several smaller components as it is illustrated in Figure 33.

image036.png

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-Loadingin 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 Modelprovides update mechanisms for both types of devices (see 8.3.4.5for 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 SoftwareUpdateTypeprovides several options where a vendor can select the parts that are necessary for the software update.

All these options are exposed as optional Referencesof the SoftwareUpdateType. A Servercan 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-Loadingor FileSystem based Loadingand it may use additional optional features like manual power cycle, parameter backup / restore or confirmation.

A Software Update Clientneeds to check which options are exposed by the Serverand how the Serverbehaves during the update (a Software Update Clientis 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.8can 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 Prepareand Resume Methodsto ensure consistency between all the steps.

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

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

For Direct-Loadingthe DirectLoadingTypeis used, which is described in 8.4.4.

The Cached-Loadingoption provides a model where the transfer of the Software Packageand its installation are separate steps. To support the Cached-Loading model the Server has to providethe Current Versionand the Pending Version. Optionally the Fallback Versioncan be supported.

With the Current Versionthe Clientcan decice if an update is required and which version to transfer. With the Pending Versionthe Clientcan ensure to install the desired version. With the Fallback Versionthe Clientcan install an alternative version.

Software Packagesare 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-Loadingthe CachedLoadingTypeis used, which is described in 8.4.5.

The Cached-Loading option with a self-contained Software Packageand 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 Loadingprovides an open structure of files and directories where a Clientcan read and write. These files could be e.g., configuration, setup files or recipes. Note: The FileSystemexposed 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 Clientand the Server. Other companion specifications could add this definition for specific types of devices. If accessed by a Software Update Client,the FileSystemroot can be used to store and install the files.

For FileSystem based Loadingthe FileSystemLoadingTypeis used, which is described in 8.4.6.

Using the Cached-Loadingoption or the FileSystemoption, a transferred Software Packageor file needs to be installed explicitly (compared to the implicit installation of Direct-Loading). Therefore, the InstallationStateMachineTypeshall 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 Clientsare 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 Clientcan subscribe to it for a user display. At least if a state machine is in an error state the UpdateStatusshould provide a meaningful error message for the user.

If the device cannot keep the parameters during the update, it shall support the Parameters Objectof the SoftwareVersionType (see 8.4.1.7). If supported by the Server, theupdate Clientshould 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 Clientmay set a ConfirmationTimeoutbefore 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 Servershall perform a rollback to enable a working Client – Serverconnection 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 WaitingForPowerCycleinforms the user that it is time to turn the power off and on again. The PowerCycleStateMachineTypeis defined in 8.4.10.

If an instance of the SoftwareUpdateTypesupports 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-Loadingit may be used in the Installingstate of the InstallationStateMachineType. For Direct-Loadingit 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 Clientis 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 Clientcan 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.

image037.png

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 Clientcan check CurrentVersionand PendingVersion Objectsto determine if the Software Packageis already transferred. With the FileSystem based Loadingthe Clientcan browse the FileSystemto find out which files are already transferred. For Cached-Loadingand File System based Loadingthe transfer can be done in advance. There are different ways to get the UpdateBehavior,because for Cached-Loadingand File System based Loadingthis depends on the actual software that should be installed (with Direct-Loadingthe server has no information about the new software). For Direct-Loadingand Cached-Loadingthe 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.

image038.png

Figure 35– Different flows of Direct-Loading, Cached-Loading andFileSystem 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.

image039.png

Figure 36– Prepare and Resume activities

The actual installation of Direct-Loadingis done during the transfer. At the end there can be a manual power cycle (option). In some cases (if the Serveris on the device that is updated) the Serveris rebooted and the Clientneeds to reconnect to complete the installation. This is illustrated in Figure 37.

image040.png

Figure 37– Installation activity for Direct-Loading

For Cached-Loadingand File System based Loadingthe installation is done using the InstallationStateMachineType. For Cached-Loadingthe InstallSoftwarePackage Methodis used and for File System based Loadingthe InstallFiles Methodis used. During this installation there may also be a manual power cycle request requiring operator input. The Clientmight also need to reconnect one or more times due to automatic reboots. If the Confirmation Objectis available, the Clientmay use it during the installation. This is illustrated in Figure 38.

image041.png

Figure 38– Installation activity for Cached-Loadingand 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.

image042.png

Figure 39– Resume activity

Especially for safety critical devices the update Clientneeds 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 Clientneeds 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 Packageneeds 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 UpdateBehaviorcan be determined with the UpdateBehavior Variable (see 8.4.4.3)of the DirectLoadingTypeor with one of the GetUpdateBehavior Methodsof 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 SoftwareRevisionbut 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 Servershould treat the installation as successful. It can inform the incompatibility using e.g., the IDeviceHealthType Interface (see 4.5.4) of thedevice / 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 AddressSpacethe software update model is defined using the AddInmodel as it is described in OPC 10001-7. An instance of SoftwareUpdateTypeshall be attached to either Objectsthat implement the Interface IVendorNameplateType(see 4.5.2) or Objectsthat support an Identification FunctionalGroup(see B.2) that implements IVendorNameplateType. For the AddIninstance 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 Servercould 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 Interfaceis used. In this Interfaceat least the Variables Manufacturer, ManufacturerUri, ProductCodeandSoftwareRevisionshall be supported and have valid values. Optionally Modeland HardwareRevisionshould be supported. TheseProperties may be shown to the operator. ManufacturerUri, ProductCodeand HardwareRevisionshould be used to identify the component.

Note that the Properties SoftwareRevision, Manufacturerand ManufacturerUrialso appears in the CurrentVersion ofthe PackageLoadingType. Their values may be different, if the manufacturer of the Deviceis 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 AddInas illustrated in the example in Figure 40.

image043.png

Figure 40– Example how to add the SoftwareUpdate AddIn to a component