The software update model defined in this clause is used to manage the software of a Device. This can include the installation of new software, the update of existing software, the update of a firmware and a limited backup and restore of parameters and firmware as far as it is needed for the update. The specific steps to perform the actual installation are only known by the device. They are not exposed by this Information Model.

The use cases that were considered for this Information Modelare described in 8.2. Several options that can be combined for a concrete SoftwareUpdateTypeinstance are described in 8.3. Valid combinations of these options are defined in the profiles section. 8.3.5describes how to implement a Software Update Client that has to deal with several options. The types for this model are formally defined in 8.4and 8.5.

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.

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

The SoftwareUpdateTypedefines an AddInwhich may be used to extend Objectswith software update features. All software update options are exposed as references of this AddIn. This way a Clientcan check for the references of the AddIn to determine which options are provided by a Server. If an option is available, it shall be used as specified.

The SoftwareUpdateTypeis illustrated in Figure 41and formally described in Table 70.

image044.png

Figure 41– SoftwareUpdateType

Table 70– SoftwareUpdateType definition

Attribute

Value

BrowseName

SoftwareUpdateType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the BaseObjectTypedefined in OPC 10000-5.

0:HasComponent

Object

Loading

SoftwareLoadingType

O

0:HasComponent

Object

PrepareForUpdate

PrepareForUpdateStateMachineType

O

0:HasComponent

Object

Installation

InstallationStateMachineType

O

0:HasComponent

Object

PowerCycle

PowerCycleStateMachineType

O

0:HasComponent

Object

Confirmation

ConfirmationStateMachineType

O

0:HasComponent

Object

Parameters

TemporaryFileTransferType

O

0:HasComponent

Variable

UpdateStatus

0:LocalizedText

0:BaseDataVariableType

O

0:HasComponent

Variable

VendorErrorCode

0:Int32

0:BaseDataVariableType

O

0:HasProperty

Variable

0:DefaultInstanceBrowseName

0:QualifiedName

0:PropertyType

Conformance Units

DI SU Software Update

The optional Loading Objectis of type SoftwareLoadingType, whichisabstract. The Objectcan be one of the concrete sub-types DirectLoadingType (8.4.4), CachedLoadingType (8.4.5) or FileSystemLoadingType (8.4.6). SoftwareLoadingTypeis formally defined in 8.4.2.

The Loading Objectis required for all variations of software installation, it is not required for read or restore of device parameters using the Parameters Object.

The optional PrepareForUpdate Objectis of type PrepareForUpdateStateMachineTypewhich is formally defined in 8.4.8.

This optional Installation Object is of type InstallationStateMachineType which is formally defined in 8.4.9.

This optional PowerCycle Objectis of type PowerCycleStateMachineType which is formally defined in 8.4.10.

This optional Confirmation Objectis of type ConfirmationStateMachineTypewhich is formally defined in 8.4.11.

This optional Parameters Objectis of type TemporaryFileTransferType (OPC 10000-5). It may be supported by devices that cannot retain parameters during update. If supported by the SoftwareUpdate AddIna Clientcan read the parameters before the update and restore them after the update. This is not a general-purpose backup and restore function. It is intended to be used in the context of software update.

The GenerateFileForReadand GenerateFileForWrite Methodsaccept an unspecified generateOptions Parameter. This argument is not used, and Clientsshall always pass null. Future versions of this specification may define concrete DataTypes.

If the restore of parameters succeeds but the software cannot run properly this should not be treated as an error of the restore. Instead, this should be indicated using the IDeviceHealthType Interfaceofthe device / component.

This optional localized string provides status and error information for the update. This may be used whenever a long running update activity can provide detailed information to the user or when a state machine wants to provide error information to the user.

A Servermay provide any text it wants to show to the operator of the software update. Important texts are the error messages in case anything went wrong, and the installation or preparation could not complete. These messages should explain what happened and how the operator could resolve the issue (e.g. “try again with a different version”). During preparation and installation, it is good practice to inform the operators about the current action to keep them patient and waiting for the completion. Also, if the installation gets stuck this text would help to find out the reason.

The UpdateStatusmay be used together with the PrepareForUpdateStateMachineType (8.4.8),theInstallationStateMachineType (8.4.9) and for CachedLoadingType (8.4.5), DirectLoadingType (8.4.4) and FileSystemLoadingType(8.4.6) it may be used during the transfer of the Software Package.

The optional VendorErrorCode Propertyprovides a machine-readable error code in case anything went wrong during the transfer, the installation or the preparation. Comparable to an error message in UpdateStatusthis Variablecan provide additional information about the issue. The VendorErrorCodeis an additional information for a Client. It is not required for normal operation and error handling.

The value 0 shall be interpreted as no error.

The VendorErrorCode may be used together with the PrepareForUpdateStateMachineType (8.4.8) for prepare and resume, in theInstallationStateMachineType (8.4.9) during the installation. For CachedLoadingType (8.4.5), DirectLoadingType (8.4.4) and FileSystemLoadingType (8.4.6) it may be used during the transfer of the Software Package.

The DefaultInstanceBrowseName Property– defined in OPC 10000-3– is required for the AddInmodel as specified in 8.3.11. It is used to specify the BrowseNameof the instance of the SoftwareUpdateType. It always has the value “SoftwareUpdate”.

Table 71– SoftwareUpdateType Attribute values for child Nodes

Source Path

Value

0:DefaultInstanceBrowseName

SoftwareUpdate

The SoftwareLoadingTypeis the abstract base for all different kinds of loading. The concrete information and behavior is modeled in its sub-types.

The SoftwareLoadingType is formally defined in Table 76.

Table 72– SoftwareLoadingType definition

Attribute

Value

BrowseName

SoftwareLoadingType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the BaseObjectTypedefined in OPC 10000-5

0:HasSubtype

ObjectType

PackageLoadingType

0:HasSubtype

ObjectType

FileSystemLoadingType

0:HasComponent

Variable

UpdateKey

0:String

0:BaseDataVariableType

O

Conformance Units

DI SU Software Update

The optional write-only UpdateKey Objectcan be used if the underlying system requires some key to unlock the update feature. The format and where to get the key is vendor-specific and not described in this specification. If UpdateKeyis supported, the Clientshall set the key before the installation. If the PrepareForUpdateStateMachineis used, the UpdateKeyshall be set before the Prepare Methodis called. The Servershall not keep the value for more than one update.

The PackageLoadingTypeprovides information about the Current Versionand allows transfer of a Software Packageto and from the Server.

The PackageLoadingType is illustrated in Figure 42and formally defined in Table 73.

image045.png

Figure 42– PackageLoadingType

Table 73– PackageLoadingType definition

Attribute

Value

BrowseName

PackageLoadingType

IsAbstract

True

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the SoftwareLoadingType

0:HasComponent

Object

CurrentVersion

SoftwareVersionType

M

0:HasComponent

Object

FileTransfer

TemporaryFileTransferType

M

0:HasComponent

Variable

ErrorMessage

0:LocalizedText

0:BaseDataVariableType

M

0:HasProperty

Variable

WriteBlockSize

0:UInt32

0:PropertyType

O

0:HasSubtype

ObjectType

DirectLoadingType

0:HasSubtype

ObjectType

CachedLoadingType

Conformance Units

DI SU Software Update

To identify the Current Version, the CurrentVersion Objectprovides ManufacturerUri, SoftwareRevisionand PatchIdentifiersalong with other information that allows the user to identify the currently used software. With this information the Clientcan determine a suitable update.

Note: This version information is about the installed software. The Manufactureris not necessarily the same as the Manufacturerof the physical device that executes the software.

The FileTransfer Objectis of type TemporaryFileTransferTypeas defined in OPC 10000-5. It is used to create temporary files for download and upload of the software.

In the TemporaryFileTransferTypetype the GenerateFileForReadand GenerateFileForWrite Methodstake an unspecified generateOptions Parameter. For the FileTransfer Objectan Enumerationof type SoftwareVersionFileTypeis used for this Parameter. It is used to select the file to upload or download. All allowed values are defined in Table 101. Additional Result Codesof the GenerateFileForReadand GenerateFileForWrite Methodsare specified in Table 74.

Table 74– TemporaryFileTransferType Result Codes

Result Code

Description

Bad_InvalidState

If the PrepareForUpdateis available, the UpdateBehaviorrequires preparation and the PrepareForUpdatestate machine is not in the state PreparedForUpdate.

Bad_NotFound

If there is no file to read from the device.

Bad_NotSupported

If the device does not support to upload / download of the Software Package.

For all errors that occur during the file transfer theErrorMessage Variableshould provide an error message for the user.

It is implementation dependent which version (see SoftwareVersionFileTypein 8.5.1) is readable and which one is writable. Additional restrictions are defined in the concrete sub-types of PackageLoadingType.

The software is transferred as a single package. File type and content are device specific. If WriteBlockSizeis supported, the Clientshall write the file in chunks of this size.

The software should be validated during the transfer process. Errors shall be indicated either in the Write Method,theCloseAndCommit Methodor an asynchronous completion of the file transfer. If the validation is performed synchronous, the Methodreturns Bad_InvalidArgument; if the validation is performed asynchronous, the error is indicated by the Errorstate of the FileTransferStateMachineType. If the ErrorMessage Variableis provided, it shall contain an error message representing the validation error.

The FileTransfer Objectmay optionally support the transfer of a Software Packagefrom the device to the Client.

If this transfer is not supported, the Servershall return the Result Code Bad_NotSupported. If it is supported but there is currently no data, the Result Code Bad_NotFoundshall be used instead.

This is a textual information about errors that can occur with the file transfer. Whenever a method of the TemporaryFileTransferType returns an error, the ErrorMessage Variableshould provide a localized error message for the user. For every new file transfer the value should be reset to an empty string.

Optional size of the blocks (number of bytes) that a Clientshall write to the file. The client shall write the Software Packagein chunks of this size to the FileTypeobject (the last block may be smaller).

The DirectLoadingTypeprovides information about the Current Versionand allows transfer of a Software Packageto and from the Server. Transfer of the Software Packageto the Serveralso includes the installation. The Direct-Loadingoption is described in 8.3.4.3.

The DirectLoadingType is illustrated in Figure 43and formally defined in Table 75.

image046.png

Figure 43– DirectLoadingType

Table 75– DirectLoadingType definition

Attribute

Value

BrowseName

DirectLoadingType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the PackageLoadingType

0:HasComponent

Variable

UpdateBehavior

UpdateBehavior

0:BaseDataVariableType

M

0:HasProperty

Variable

WriteTimeout

Duration

0:PropertyType

O

Conformance Units

DI SU DirectLoading

The FileTransfer Objectis inherited from the PackageLoadingType. In this sub-type the Current versionshall be writable (see SoftwareVersionFileTypein 8.5.1). Writing to this file also includes the actual installation.

The UpdateBehavior OptionSetinforms the update Clientabout the specific behavior of the component during update via Direct-Loading.

Optional Propertythat informs the Clientabout the maximum duration of the call to the Write Methodof FileType(maximum time the write of a block of data can take). If the write operation takes longer the Clientcan assume that the Serverhas an issue.

The CachedLoadingTypeprovides information about the Current Version, the Pending Versionand the Fallback Version(if supported). Additionally, it allows upload and download of different versions of the software. The Cached-Loadingoption is described in 8.3.4.4.

The CachedLoadingTypeis illustrated in Figure 44and formally defined in Table 76.

image047.png

Figure 44– CachedLoadingType

Table 76– CachedLoadingType definition

Attribute

Value

BrowseName

CachedLoadingType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the PackageLoadingType

0:HasComponent

Object

PendingVersion

SoftwareVersionType

M

0:HasComponent

Object

FallbackVersion

SoftwareVersionType

O

0:HasComponent

Method

GetUpdateBehavior

M

Conformance Units

DI SU CachedLoading

The FileTransfer Objectis inherited from the PackageLoadingType. In this sub-type the Current versionshall not be writable and the Pending versionshall be writable (see SoftwareVersionFileTypein 8.5.1).

The PendingVersion Objectdescribes an already transferred new Software Packagethat is ready to be installed.

If there is no Software Packageavailable, the values should be empty.

The optional FallbackVersion Objectdescribes an alternate version on the device. This could be a factory default version or the version before the last update. Installing the Fallback Versionmay be used to revert to a reliable version of the software.

If a Fallback Versionis supported by the device the object shall be available. If there is currently no Fallback Versionon the device, the values should be empty.

With this Methodthe Clientmay check the specific update behavior for a specified software version. To identify the version the GetUpdateBehavior Methodrequires the ManufacturerUri, SoftwareRevision and PatchIdentifiers Propertiesof the SoftwareVersionType.

Signature

GetUpdateBehavior(

[in]0:String ManufacturerUri,

[in]0:String SoftwareRevision,

[in]0:String[] PatchIdentifiers,

[out]UpdateBehaviorUpdateBehavior);

Table 77– GetUpdateBehavior Method Arguments

Argument

Description

ManufacturerUri

ManufacturerUri Property of either the Pendingor Fallback SoftwareVersionTypethat should be installed.

SoftwareRevision

SoftwareRevision Property of either the Pendingor Fallback SoftwareVersionTypethat should be installed.

PatchIdentifiers

PatchIdentifiers Property of either the Pendingor Fallback SoftwareVersionTypethat should be installed. (or empty array if not supported by the SoftwareVersionTypeinstance)

UpdateBehavior

Update behavior option set for the specified SoftwareVersionType instance

Method Result Codes (defined in Call Service)

Result Code

Description

Bad_NotFound

If the Software Package, identified by the parameters, does not exist.

Table 78– GetUpdateBehavior Method AddressSpace definition

Attribute

Value

BrowseName

GetUpdateBehavior

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

0:HasProperty

Variable

InputArguments

0:Argument[]

0:PropertyType

M

0:HasProperty

Variable

OutputArguments

0:Argument[]

0:PropertyType

M

Conformance Units

DI SU CachedLoading

The FileSystemLoadingTypeenables software update based on an open file system. This enables the FileSystem based Loadingoption of 8.3.4.5.

It is illustrated in Figure 45and formally defined in Table 79.

image048.png

Figure 45– FileSystemLoadingType

Table 79– FileSystemLoadingType definition

Attribute

Value

BrowseName

FileSystemLoadingType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the SoftwareLoadingType

0:HasComponent

Object

0:FileSystem

0:FileDirectoryType

M

0:HasComponent

Method

GetUpdateBehavior

M

0:HasComponent

Method

ValidateFiles

O

Conformance Units

DI SU FileSystem Loading

The FileSystem Objectis of type FileDirectoryTypeas it is defined in OPC 10000-5. It provides access to a hierarchy of directories and files of the device. The structure may be read and written by the Clienthowever the device may restrict this for specific folders or files.

This Methodmay be used to check the specific update behavior for a set of files. The files are identified by the NodeIdof their FileTypeinstance in the FileSystem.

Signature

GetUpdateBehavior(

[in] 0:NodeId[] NodeIds, ,

[out] UpdateBehaviorUpdateBehavior);

Table 80– GetUpdateBehavior Method Arguments

Argument

Description

NodeIds

NodeIds of the files to install.

UpdateBehavior

Update behavior OptionSetfor the files specified by NodeId

Method Result Codes (defined in Call Service)

Result Code

Description

Bad_NotFound

If one or more NodeIdsare not found.

Table 81– GetUpdateBehavior Method AddressSpace definition

Attribute

Value

BrowseName

GetUpdateBehavior

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

0:HasProperty

Variable

InputArguments

0:Argument[]

0:PropertyType

M

0:HasProperty

Variable

OutputArguments

0:Argument[]

0:PropertyType

M

Conformance Units

DI SU FileSystem Loading

This Methodmay be used to check if the specified set of files are valid and complete for an installation. This should also include dependency checks if appropriate.

Note: In case of Direct-Loadingor Cached-Loadingthese checks should be part of the transfer and this method shall not be supported since it is part of the file transfer (e.g., in CloseAndCommit).

Signature

ValidateFiles(

[in] 0:NodeId[] NodeIds,

[out] 0:Int32 ErrorCode,

[out] 0:LocalizedTextErrorMessage);

Table 82– ValidateFiles Method Arguments

Argument

Description

NodeIds

NodeIds of the files to validate.

ErrorCode

0 for success or device specific number for validation issues.

ErrorMessage

Message for the user that describes how to resolve the issue.

Method Result Codes (defined in Call Service)

Result Code

Description

Bad_NotFound

If one or more NodeIdsare not found.

Table 83– ValidateFiles Method AddressSpace definition

Attribute

Value

BrowseName

ValidateFiles

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

0:HasProperty

Variable

InputArguments

0:Argument[]

0:PropertyType

M

0:HasProperty

Variable

OutputArguments

0:Argument[]

0:PropertyType

M

Conformance Units

DI SU FileSystem Loading

The SoftwareVersionTypeidentifies a concrete version of a software. It is used by the CachedLoadingType(8.4.5) and the DirectLoadingType(8.4.4) to store the version information.

The Description Attributeon the instances of the SoftwareVersionTypeshould be used to provide additional information about the concrete version of the software to the user (e.g., change notes).

The SoftwareVersionTypeis illustrated in Figure 46and formally defined in Table 84.

image049.png

Figure 46– SoftwareVersionType

Table 84– SoftwareVersionType definition

Attribute

Value

BrowseName

SoftwareVersionType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the BaseObjectTypedefined in OPC 10000-5

0:HasProperty

Variable

Manufacturer

0:LocalizedText

0:PropertyType

M

0:HasProperty

Variable

ManufacturerUri

0:String

0:PropertyType

M

0:HasProperty

Variable

SoftwareRevision

0:String

0:PropertyType

M

0:HasProperty

Variable

PatchIdentifiers

0:String[]

0:PropertyType

O

0:HasProperty

Variable

ReleaseDate

0:DateTime

0:PropertyType

O

0:HasProperty

Variable

ChangeLogReference

0:String

0:PropertyType

O

0:HasProperty

Variable

Hash

0:ByteString

0:PropertyType

O

Conformance Units

DI SU Software Update

The read only Manufacturer Propertyprovides the name of the company that created the software.

In case of the Pending Versionthis shall be empty if there is no pending software to install.

The read only ManufacturerUri Propertyprovides a unique identifier for the manufacturer of the software.

In case of the Pending Versionthis shall be empty if there is no pending software to install.

The read only SoftwareRevision Propertydefines the version of the software. The format and semantics of the string is vendor-specific. SemanticVersionString(a sub-type of Stringdefined in OPC 10000-5) may be used when using the Semantic Versioning format.

In case of the Pending Versionthis shall be empty if there is no pending software to install.

The read only PatchIdentifiers Propertyidentifies the list of patches that are applied to a software version. The format and semantics of the strings are vendor-specific. The order of the strings shall not be relevant.

The read only ReleaseDate Propertydefines the date when the software is released. If the version information is about patches, this should be the date of the latest patch. It is additional information for the user.

The read only ChangeLogReference Propertymay optionally provide a URL to a web site with detailed information about the particular version of the software (change notes). In case of a patched software, the web site should also inform about the patches.

The optional read only Hash Propertymay be read by a Clientto get the hash of a previously transferred Software Package. The hash value needs to be calculated by the Serverwith the SHA-256 algorithm. It can be used to verify if the transferred package matches the one at the Client.

The PrepareForUpdateStateMachineTypemay be used if the device requires to be prepared before the update. Another option is to delay the resuming of normal operation until all update actions are executed. This supports to prepare for update option of 8.3.4.2.

If a Serverimplements this state machine, a Clientshall use it except if the UpdateBehaviorindicates that this is not necessary for the transferred software. If preparation is required, the installation is only allowed if the PrepareForUpdateStateMachineis in the PreparedForUpdatestate.

The state machine is illustrated in Figure 47, Figure 48and formally defined in Table 85. The transitions are formally defined in Table 87.

image050.png

Figure 47– PrepareForUpdate state machine

image051.png

Figure 48– PrepareForUpdateStateMachineType

Table 85– PrepareForUpdateStateMachineType definition

Attribute

Value

BrowseName

PrepareForUpdateStateMachineType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the FiniteStateMachineTypedefined in OPC 10000-5.

0:HasComponent

Variable

PercentComplete

0:Byte

0:BaseDataVariableType

O

0:HasComponent

Method

Prepare

M

0:HasComponent

Method

Abort

M

0:HasComponent

Method

Resume

O

0:HasComponent

Object

Idle

0:InitialStateType

0:HasComponent

Object

Preparing

0:StateType

0:HasComponent

Object

PreparedForUpdate

0:StateType

0:HasComponent

Object

Resuming

0:StateType

0:HasComponent

Object

IdleToPreparing

0:TransitionType

0:HasComponent

Object

PreparingToIdle

0:TransitionType

0:HasComponent

Object

PreparingToPreparedForUpdate

0:TransitionType

0:HasComponent

Object

PreparedForUpdateToResuming

0:TransitionType

0:HasComponent

Object

ResumingToIdle

0:TransitionType

Conformance Units

DI SU PrepareForUpdate

The component Variablesof the PrepareForUpdateStateMachineTypehave additional Attributesdefined in Table 86.

Table 86– PrepareForUpdateStateMachineType Attribute values for child Nodes

BrowsePath

Value Attribute

Idle

0:StateNumber

1

Preparing

0:StateNumber

2

PreparedForUpdate

0:StateNumber

3

Resuming

0:StateNumber

4

IdleToPreparing

0:TransitionNumber

12

PreparingToIdle

0:TransitionNumber

21

PreparingToPreparedForUpdate

0:TransitionNumber

23

PreparedForUpdateToResuming

0:TransitionNumber

34

ResumingToIdle

0:TransitionNumber

41

Table 87– PrepareForUpdateStateMachineType Additional References

SourceBrowsePath

Reference Type

Is Forward

TargetBrowsePath

Transitions

IdleToPreparing

0:FromState

True

Idle

0:ToState

True

Preparing

0:HasEffect

True

0:TransitionEventType

PreparingToIdle

0:FromState

True

Preparing

0:ToState

True

Idle

0:HasEffect

True

0:TransitionEventType

PreparingToPreparedForUpdate

0:FromState

True

Preparing

0:ToState

True

PreparedForUpdate

0:HasEffect

True

0:TransitionEventType

PreparedForUpdateToResuming

0:FromState

True

PreparedForUpdate

0:ToState

True

Resuming

0:HasEffect

True

0:TransitionEventType

ResumingToIdle

0:FromState

True

Resuming

0:ToState

True

Idle

0:HasEffect

True

0:TransitionEventType

This percentage is a number between 0 and 100 that informs about the progress in the Preparingor the Resuming States. It may be used whenever the activity takes longer and the user should be informed about the completion. If the state machine is in Idleor PreparedForUpdate Stateit shall have the value 0.

Note: This information is for the user only. It shall not be used to detect completion of the transition.

The Prepare Methodmay be called to prepare a device for an update. This call transitions the device into the state Preparing.

After the preparation is complete the state machine may perform an automatic transition to the state PreparedForUpdate.

If the preparation cannot complete and the device does not get prepared for update the state machine transitions back to Idle. In this case a message with the reason should be provided to the user via the UpdateStatus.

Signature

Prepare();

Method Result Codes (defined in Call Service)

Result Code

Description

Bad_InvalidState

If the PrepareForUpdateStateMachineType is not in Idle state.

If the preparation takes too long or does not complete at all because the required internal conditions are not met the Abort Methodmay be called to abort the preparation. This call transitions the device back to the Idlestate.

Note: If the transition from Preparingto Idlecannot complete instantly a Clientneeds to subscribe for the events or the state variable of the PrepareForUpdateStateMachine.

Signature

Abort();

Method Result Codes (defined in Call Service)

Result Code

Description

Bad_InvalidState

If the PrepareForUpdateStateMachineType is not in Preparing state.

A call to the optional Resume Methodtransitions the device into the state Resuming. After the resuming is complete the state machine performs an automatic transition to the Idlestate. If the method is not supported, the transitions to Resumingand back to Idleshall be done by the Serverautomatically. If the method is supported, there shall not be an automatic transition to Resuming.Supporting this method enables the Clientto group several activities like backup, install, restore on a single device or group the update of multiple devices before the devices are allowed to Resume their operation again.

Signature

Resume();

Method Result Codes (defined in Call Service)

Result Code

Description

Bad_InvalidState

If the PrepareForUpdateStateMachineType is not in PreparedForUpdate state or if the InstallationStateMachine is still in the state Installing.

The InstallationStateMachineTypemay be used if the device supports explicit installation (Cached-Loadingor File System based Loading). This supports the installation option of 8.3.4.6. It is illustrated in Figure 49and Figure 50and formally defined in Table 88. The transitions are formally defined in Table 90.

image052.png

Figure 49– Installation state machine

image053.png

Figure 50– InstallationStateMachine

Table 88– InstallationStateMachineType definition

Attribute

Value

BrowseName

InstallationStateMachineType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the FiniteStateMachineTypedefined in OPC 10000-5.

0:HasComponent

Variable

PercentComplete

0:Byte

0:BaseDataVariableType

O

0:HasComponent

Variable

InstallationDelay

0:Duration

0:BaseDataVariableType

O

0:HasComponent

Method

InstallSoftwarePackage

O

0:HasComponent

Method

InstallFiles

O

0:HasComponent

Method

Resume

M

0:HasComponent

Object

Idle

0:InitialStateType

0:HasComponent

Object

Installing

0:StateType

0:HasComponent

Object

Error

0:StateType

0:HasComponent

Object

IdleToInstalling

0:TransitionType

0:HasComponent

Object

InstallingToIdle

0:TransitionType

0:HasComponent

Object

InstallingToError

0:TransitionType

0:HasComponent

Object

ErrorToIdle

0:TransitionType

Conformance Units

DI SU Software Update

The component Variablesof the InstallationStateMachineTypehave additional Attributesdefined in Table 89.

Table 89– InstallationStateMachineType Attribute values for child Nodes

BrowsePath

Value Attribute

Idle

0:StateNumber

1

Installing

0:StateNumber

2

Error

0:StateNumber

3

IdleToInstalling

0:TransitionNumber

12

InstallingToIdle

0:TransitionNumber

21

InstallingToError

0:TransitionNumber

23

ErrorToIdle

0:TransitionNumber

31

Table 90– InstallationStateMachineType Additional References

SourceBrowsePath

Reference Type

Is Forward

TargetBrowsePath

Transitions

IdleToInstalling

0:FromState

True

Idle

0:ToState

True

Installing

0:HasEffect

True

0:TransitionEventType

InstallingToIdle

0:FromState

True

Installing

0:ToState

True

Idle

0:HasEffect

True

0:TransitionEventType

InstallingToError

0:FromState

True

Installing

0:ToState

True

Error

0:HasEffect

True

0:TransitionEventType

ErrorToIdle

0:FromState

True

Error

0:ToState

True

Idle

0:HasEffect

True

0:TransitionEventType

This percentage is a number between 0 and 100 that informs the user about the progress of an installation. It should be used whenever an update activity takes longer and the user should be informed about the completion. If the state machine is in Idle Stateit shall have the value 0. In case of an error the last value should be kept until the Resumeis called.

Note: This information is for the user only. It shall not be used to detect completion of the installation.

The optional InstallationDelaycan be set by a Clientto delay the actual installation after the call to InstallSoftwarePackageor InstallFilesis returned by the Server. This can be used when the installation is started on several devices in parallel and there is a risk that a reboot of one device could harm the connection to other devices. With a delay the install methods can be called on all devices before the devices actually start the installation. The InstallationDelaydoes not delay the transition from Idleto Installing.

This value could be preconfigured. If a Clientwants to set this value it has to be done before the install method is called.

The Serveris expected to stay operational at least during the delay.

With this Methodthe Clientrequests the installation of a Software Package. The package can be either the previously transferred Pending Versionor the alternative Fallback Version. To identify the version and to prevent conflicts with a second Clientthat transfers a different version, the InstallSoftwarePackage Methodneeds the ManufacturerUri, the SoftwareRevision and PatchIdentifiers Propertiesof the SoftwareVersionType.

Optionally an additional hash value may be passed to the Method. This hash could be calculated by the Clientor taken from a trusted source. Before installation the Servermay compare the hash against the calculated hash of the Software Package. This mechanism can be used if there is a risk that the Software Packageis altered during the transfer to the device and if the Serverhas no other mechanism to ensure that the Software Packageis from a trustworthy source.

If the installation succeeds but the software cannot run properly this should not be treated as an error of the installation. Instead, this should be indicated using the IDeviceHealthType Interface of the device / component.

This Methodshall not return before the state has changed to the Installingstate.

Signature

InstallSoftwarePackage(

[in] 0:String ManufacturerUri,

[in] 0:String SoftwareRevision,

[in] 0:String[] PatchIdentifiers,

[in] 0:ByteString Hash);

Table 91– InstallSoftwarePackage Method Arguments

Argument

Description

ManufacturerUri

ManufacturerUri Property of either the Pendingor Fallback SoftwareVersionTypethat should be installed.

SoftwareRevision

SoftwareRevision Property of either the Pendingor Fallback SoftwareVersionTypethat should be installed.

PatchIdentifiers

PatchIdentifiers Property of either the Pendingor Fallback SoftwareVersionTypethat should be installed. (or empty array if not supported on the SoftwareVersionType instance).

Hash

Hash of the Software Packagethat should be installed (or empty if not used).

Method Result Codes (defined in Call Service)

Result Code

Description

Bad_InvalidState

If the InstallationStateMachineTypeis not in Idlestate or if the PrepareForUpdate Objectis available and the PrepareForUpdatestate machine is not in the state PreparedForUpdate.

Bad_NotFound

If the specified Software Packagedoes not exist.

Bad_InvalidArgument

If the Hash does not match the calculated hash of the Software Package.

Table 92– InstallSoftwarePackage Method AddressSpace definition

Attribute

Value

BrowseName

InstallSoftwarePackage

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

0:HasProperty

Variable

InputArguments

0:Argument[]

0:PropertyType

M

Conformance Units

DI SU Software Update

This Methodmay be called to request the installation of one or more files. The files are identified by the NodeIdof their FileTypeinstance in the FileSystem.

If the installation succeeds but the software cannot run properly this should not be treated as an error of the installation. Instead, this should be indicated using the IDeviceHealthType Interface of the device / component.

Signature

InstallFiles(

[in] 0:NodeId[] NodeIds);

Table 93– InstallFiles Method Arguments

Argument

Description

NodeIds

NodeIds of the files to install.

Method Result Codes (defined in Call Service)

Result Code

Description

Bad_InvalidState

If the InstallationStateMachineTypeis not in Idlestate or if the PrepareForUpdate Objectis available and the PrepareForUpdatestate machine is not in the state PreparedForUpdate.

Bad_NotFound

If one or more NodeIds are not found.

Table 94– InstallFiles Method AddressSpace definition

Attribute

Value

BrowseName

InstallFiles

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

0:HasProperty

Variable

InputArguments

0:Argument[]

0:PropertyType

M

Conformance Units

DI SU Software Update

This Methodmay be called to resume from the Errorstate. The Errorstate can be reached if there are issues during the installation. The state machine remains in this state until the Clientcalls the Resume Methodto get back to the Idlestate immediately.

Signature

Resume();

Method Result Codes (defined in Call Service)

Result Code

Description

Bad_InvalidState

If the InstallationStateMachineTypeis not in Error state.

The PowerCycleStateMachineTypeis used to inform the user to perform a manual power cycle.

When the server needs a manual power cycle it indicates that to the client by changing the state to WaitingForPowerCycle. After restart of the Device,it transitions to NotWaitingForPowerCycleautomatically.

There are no methods, all transitions originate from the installation process. The state machine is illustrated in Figure 51and formally defined in Table 95. The transitions are formally defined in Table 97.

image054.png

Figure 51– PowerCycle state machine

Table 95– PowerCycleStateMachineType definition

Attribute

Value

BrowseName

PowerCycleStateMachineType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:FiniteStateMachineTypedefined in OPC 10000-5.

0:HasComponent

Object

NotWaitingForPowerCycle

0:InitialStateType

0:HasComponent

Object

WaitingForPowerCycle

0:StateType

0:HasComponent

Object

NotWaitingForPowerCycleToWaitingForPowerCycle

0:TransitionType

0:HasComponent

Object

WaitingForPowerCycleToNotWaitingForPowerCycle

0:TransitionType

Conformance Units

DI SU Manual Power Cycle

The component Variablesof the PowerCycleStateMachineTypehave additional Attributesdefined in Table 96.

Table 96– PowerCycleStateMachineType Attribute values for child Nodes

BrowsePath

Value Attribute

NotWaitingForPowerCycle

0:StateNumber

1

WaitingForPowerCycle

0:StateNumber

2

NotWaitingForPowerCycleToWaitingForPowerCycle

0:TransitionNumber

12

WaitingForPowerCycleToNotWaitingForPowerCycle

0:TransitionNumber

21

Table 97– PowerCycleStateMachineType Additional References

SourceBrowsePath

Reference Type

Is Forward

TargetBrowsePath

Transitions

NotWaitingForPowerCycleToWaitingForPowerCycle

0:FromState

True

NotWaitingForPowerCycle

0:ToState

True

WaitingForPowerCycle

0:HasEffect

True

0:TransitionEventType

WaitingForPowerCycleToNotWaitingForPowerCycle

0:FromState

True

WaitingForPowerCycle

0:ToState

True

NotWaitingForPowerCycle

0:HasEffect

True

0:TransitionEventType

The ConfirmationStateMachineTypeis used to prove a valid Client – Serverconnection after a restart of the OPC UA Server. This supports the confirmation option of 8.3.4.9.

If several instances of this state machine are provided on a device (due to several instances of the SoftwareUpdateType), all instances should behave as if it is only a single instance. In particular it is sufficient to call one of the confirm methods after reboot.

The ConfirmationStateMachineTypeis illustrated in Figure 52and Figure 53and formally defined in Table 98. The transitions are formally defined in Table 100.

image055.png

Figure 52– Confirmation state machine

image056.png

Figure 53– ConfirmationStateMachineType

Table 98– ConfirmationStateMachineType

Attribute

Value

BrowseName

ConfirmationStateMachineType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the FiniteStateMachineTypedefined in OPC 10000-5.

0:HasComponent

Method

Confirm

M

0:HasComponent

Variable

ConfirmationTimeout

0:Duration

0:BaseDataVariableType

M

0:HasComponent

Object

NotWaitingForConfirm

0:InitialStateType

0:HasComponent

Object

WaitingForConfirm

0:StateType

0:HasComponent

Object

NotWaitingForConfirmToWaitingForConfirm

0:TransitionType

0:HasComponent

Object

WaitingForConfirmToNotWaitingForConfirm

0:TransitionType

Conformance Units

DI SU Update Confirmation

The component Variablesof the ConfirmationStateMachineTypehave additional Attributesdefined in Table 99.

Table 99– ConfirmationStateMachineType Attribute values for child Nodes

BrowsePath

Value Attribute

NotWaitingForConfirm

0:StateNumber

1

WaitingForConfirm

0:StateNumber

2

NotWaitingForConfirmToWaitingForConfirm

0:TransitionNumber

12

WaitingForConfirmToNotWaitingForConfirm

0:TransitionNumber

21

Table 100– ConfirmationStateMachineType TargetBrowsePath

SourceBrowsePath

Reference Type

Is Forward

TargetBrowsePath

Transitions

NotWaitingForConfirmToWaitingForConfirm

0:FromState

True

NotWaitingForConfirm

0:ToState

True

WaitingForConfirm

0:HasEffect

True

0:TransitionEventType

WaitingForConfirmToNotWaitingForConfirm

0:FromState

True

WaitingForConfirm

0:ToState

True

NotWaitingForConfirm

0:HasEffect

True

0:TransitionEventType

The ConfirmationTimeout may be set by a Clientto a value other then 0 to enable the confirmation feature. If the value is not 0 and the ClientServerconnection is lost, the ConfirmationTimeoutrepresents the maximum time that the Clientmay need to reconnect and call the Confirm Method. The Servershall automatically reset the value to 0 when the installation is complete.

After a reboot and with a ConfirmationTimeoutother than 0 a Clientshall call this Methodto inform the Serverthat it has successfully reconnected. If this Methodis not called after a lost connection the Servershall regard the update as unsuccessful and shall revert it. A Clientneeds to react within the time specified in the ConfirmationTimeout Variable.

Signature

Confirm();

This enumeration is used to identify the version in the methods of the TemporaryFileTransferTypethat is used in the PackageLoadingType (8.4.3). The Enumerationis defined in Table 101. Its representation in the AddressSpaceis defined in Table 102.

Table 101– SoftwareVersionFileType Items

Name

Value

Description

Current

0

The currently used version of the software identified by the CurrentVersion Object.

Pending

1

The Pending Versionof the software that could be installed identified by the PendingVersion Object.

Fallback

2

The Fallback Versionof the software identified by the FallbackVersion Object.

Table 102– SoftwareVersionFileType definition

Attribute

Value

BrowseName

SoftwareVersionFileType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:Enumeration type defined in OPC 10000-5

0:HasProperty

Variable

0:EnumStrings

0:LocalizedText []

0:PropertyType

Conformance Units

DI SU Software Update

The UpdateBehavior OptionSetis based on UInt32. It describes how the device can perform the update. All possible options are described in Table 103. All other values are reserved for future versions of this specification. The OptionSetis used in the UpdateBehavior Propertyof the DirectLoadingType(8.4.4.3) and in the GetUpdateBehavior Methodson the CachedLoadingType(8.4.5.5) and in the FileSystemLoadingType(8.4.6.3).

Table 103– UpdateBehavior OptionSet

Value

Bit No.

Description

KeepsParameters

0

If KeepsParameters is not set, the device will lose its configuration during update. The Clientshould do a backup of the parameters before the update and restore them afterwards.

WillDisconnect

1

If WillDisconnect is set, the OPC UA Serverwill restart during installation. This can be the case if the update is about the firmware of the device that hosts the OPC UA Server.

RequiresPowerCycle

2

If RequiresPowerCycle is set, the devices require a manual power off / power on for installation.

WillReboot

3

If WillReboot is set, the device will reboot during the update, inclusive of embedded infrastructure elements like an integrated switch. An update Clientshould take this into account since the devices behind an integrated switch are not reachable for that time.

NeedsPreparation

4

If NeedsPreparation is not set, the Clientcan install the update without maintaining the PrepareForUpdateStateMachine. This can be used to support an installation without stopping the software.

The UpdateBehavior OptionSetrepresentation in the AddressSpaceis defined in Table 104.

Table 104– UpdateBehavior OptionSet Definition

Attribute

Value

BrowseName

UpdateBehavior

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of 0:UInt32 defined in OPC 10000-5.

0:HasProperty

Variable

OptionSetValues

0:LocalizedText[]

0:PropertyType

Conformance Units

DI SU Software Update