To support an individual software update for the devices of a Server AddressSpace the software update model is defined using the AddIn model as it is described in OPC 10001-7. An instance of SoftwareUpdateType shall be attached to either Objects that implement the Interface IVendorNameplateType (see 4.5.2) or Objects that support an Identification FunctionalGroup (see B.2) that implements IVendorNameplateType. For the AddIn instance 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 Server could 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 Interface is used. In this Interface at least the Variables Manufacturer, ManufacturerUri, ProductCode and SoftwareRevision shall be supported and have valid values. Optionally Model and HardwareRevision should be supported. These Properties may be shown to the operator. ManufacturerUri, ProductCode and HardwareRevision should be used to identify the component.

Note that the Properties SoftwareRevision, Manufacturer and ManufacturerUri also appears in the CurrentVersion of the PackageLoadingType. Their values may be different, if the manufacturer of the Device is 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 AddIn as illustrated in the example in Figure 40.

image043.png

Figure 40 – Example how to add the SoftwareUpdate AddIn to a component