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).