The software updatemodel 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 Clientsoftware. 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.5describes 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 AddInsdescribed 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 Clientalso 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 Clientcan 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 Clientcan 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-Serverconnection is required. The scheduling is a task of the Clientand 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 Packageindependently 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 ClientServerconnection. This requires an additional confirmation by the update Client,so that the Servercan 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 Clientneeds 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 Packageto 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 Servercan expose information about the device (8.3.11) and information about the Current Version(8.4.3.2) which is then used by the Clientto 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 Modelshould allow the Clientto transfer and install additional software applications, if the Serversupports this. This can be done using the FileSystem based Loading(8.3.4.5).

If an OPC UA Serverabstracts several devices that support the SoftwareUpdate AddIn, the Information Modelshall 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 FolderTypebelow DeviceFeaturesas 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 Clientwould tell the Serveronly 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.