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 might 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 needs to be stopped before the update, whereas in process domain e.g., a redundant device needs to 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 address space. 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 might first need to be 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 measuered in the device. If a controller needs to be updated in process automation it often needs to be the passive part of a redundant set of controllers.

A Client also needs to consider 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 need to be replaced, there is a need to maintain the individual files of the Software Package independently on the Server. 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 constraint devices may lose parameters during the update. The update Client needs to be 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 need to be restored. This can be supported using the Parameters object (8.3.4.8).

An update client needs to select 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 needs to be 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).

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 might be useful outside of software update it should be realized somewhere outside this specification.

Sometimes it is desirable to store all files needed 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.