The software update model is used in several scenarios. The following subsections list common use cases that are considered by this model. There are also some use cases that that are not covered. A future version could possibly add features for them.

The model is intended to be applicable across devices with varying resources and constraints. This is achieved e.g. by various options for the server implementation (see 8.3.4).

Allow devices to be updated via Software Update Client software. To address the domain specific constraints this can be a domain-specific client software. (In the manufacturing domain a machine often necessitates to be stopped before the update, whereas in process domain e.g., a redundant device will be activated.) 8.3.5 describes the workflow of a Software Update Client.

Software update is applicable for any device or software component that is exposed in the Server AddressSpace. This can also represent other devices that are just connected to the device hosting the Server. This can be done using the AddIns described in 8.3.11.

When updating several connected devices in a machine or plant the devices possibly are first set into a special “state” where they wait for the start of the update and don’t start operating again. After that the updates can be installed in an order defined by the Client (e.g., sensors first, switches last). Finding the best sequence is task of the client implementation or the operator and not in scope of this specification.

The “state” is defined depending on the type of machine / plant. For factory automation this normally means that production and the software on the devices is stopped. For a sensor in process automation this could mean that a replacement value is configured in the controller for the value measured in the device. If a controller requires an update in process automation it often is the passive part of a redundant set of controllers.

It is also necessary that the Client considers the proper sequence when updating the devices. For example, if parts of the network become unreachable due to the update of an infrastructure device.

A server can support the prepare for update option (8.3.4.2) to enable this use case.

For some updates it is not necessary to stop the software. This could be the case if parts of a software are replaced that are currently not used or if new software is installed. Whether an update can be installed like this is only known by the device and depends on the concrete update file. To support this, the Client can read the UpdateBehavior (8.5.2) to determine if stopping is required.

In some cases, it is required to prepare the update and then plan the start for a later time or under some strategic conditions. In this case the software is transferred to the device first. Later (e.g., at the end of the shift or on the weekend) and under specific conditions (e.g. nothing to produce) the update Client can start the update. In this scenario the time and the conditions are known and checked by the update Client, not by the Server, so for the use of the software update options an established Client-Server connection is required. The scheduling is a task of the Client and not described in this specification.

It should be possible to distribute the software to several devices without actual installation. In this scenario a central tool can determine the required updates and distribute them to all devices. The actual installation can then be started later by a different Client. This is realized by separating the transfer (8.4.1.2) from the installation (8.3.4.6).

Depending on the device there should be several options to partition a software. For example, it should be possible to structure the firmware of a device in a way that each part can be updated individually. Additionally, software update should be applicable to the firmware of devices and to the software of components. This is realized with the AddIn model (8.3.11).

If a Software Package becomes very large and only parts of it can be replaced, the Server maintains the individual files of the Software Package independently. When all desired files are on the Server, the installation can be started for the set of files. Here the FileSystem option (8.3.4.5) can be used.

Especially for devices that are not easy to access for a manual reset or replacement, the update shall always result in a working OPC UA Client – Server connection. This requires an additional confirmation by the update Client, so that the Server can do an automatic rollback if the communication cannot be established again after a reboot. A Server can support this with the confirmation option (8.3.4.9).

Very constrained devices can lose parameters during the update. It is necessary that the update Client is aware of that and should be able to backup the parameters in advance. After the update – but before the device starts operating again – the parameters shall be restored. This can be supported using the Parameters object (8.3.4.8).

An update client selects the correct version of the Software Package to install. The rules behind this decision can be complex and can include e.g., dependency checks or a release process of the distributor and / or operator of the machine. The Server can expose information about the device (8.3.11) and information about the Current Version (8.4.3.2) which is then used by the Client to select an update.

Selecting the new version is done by the user with the help of the update client before transfer and installation. Therefore, it is not in scope of this specification.

Some devices can run several software applications. The Information Model should allow the Client to transfer and install additional software applications if the Server supports this. This can be done using the FileSystem based Loading (8.3.4.5) or the SoftwareFolderType (8.4.12).

An Update Client imports a software along with all metadata and all supporting files. These files can come from different vendors for different devices. For easier transport and handling, a single standardized container file is required.

The Software Update AddIn supports atomic transfer of a single file to the server. To keep the metadata together with the transferred file a standard container file format is required.Additionally, a server possibly wants to store multiple files (to prevent nesting ZIP in ZIP).

If a working device is used as the prototype for other devices the Software Package of an application or configuration can be uploaded. Therefore, an embedded device should be able to create a Software Package and upload it using the SoftwareUpdate AddIn. This package can also be used for backup.

An Update Client identifies Software Packages that are installable to a SoftwareUpdate AddIn found on the server. For example, getting suitable firmware packages from a repository for a device, which is identified by ManufacturerUri and ProductCode.

An Update Client checks the compatibility before transfer anything to a device. This includes selecting the proper version as a valid update.

An Update Client ensures that all dependent hardware / firmware / software components have suitable versions.

An Update Client presents additional files to the user. This can include release notes, license information, manuals.

An Update Client verifies the integrity and authenticity of the files within the Software Package.

In some plants it is required that only those Software Packages can be installed onto the devices that are tested and approved for use in that plant. In that cases the devices is configured to only accept Software Packages with a specific approval signature.

At system design a combination of several devices or several software instances on a single device or machine or UA Server is defined and released. Example: modular devices like PLC, IO Island or Machine. For that case it shall be possible to sign this combination and transfer all related files in a single container. A target shall be configurable to only accept such combinations with a specific valid signature.

If an OPC UA Server abstracts several devices that support the SoftwareUpdate AddIn, the Information Model shall provide a defined entry point to find all these devices in an efficient manner.

This Use Case is expected to be addressed in other working groups or in a future version of this specification.

A possible solution would be to create a SWUpdate FolderType below DeviceFeatures as it is described in the DI specification. This folder could reference all SoftwareUpdate AddIns.

In most update scenarios the device can restart automatically during or after the installation. However, there can be situations where it is required to explicitly restart the device by the Client.

This use case is not supported by the current version of this specification. Since this feature can be useful outside of software update it should be realized somewhere outside this specification.

Sometimes it is desirable to store all files required for software update at a central place and have the devices get the files on their own time and pace. In this case the Client would tell the Server only the location of the file. Then the actual transfer is initiated by the device.

There is no specific support for this use case in this specification. However, it is possible to use the described mechanisms to transfer a file that does not contain the actual software but the location of the external source(s) where the software file(s) should be pulled from.