This Annex includes examples referenced in the normative sections.

The examples in Figure B.1 and Figure B.2 illustrate the use of FunctionalGroups:

image061.png

Figure B.1 – Analyser Device use for FunctionalGroups

image062.png

Figure B.2 – PLCopen use for FunctionalGroups

The Properties of a TopologyElement, like Manufacturer, SerialNumber, will usually be sufficient as identification. If other Parameters or even Methods are required, all elements needed shall be organized in a FunctionalGroup called Identification. Figure B.3 illustrates the Identification FunctionalGroup with an example.

Note that companion standards are expected to define the Identification contents for their model.

image063.png

Figure B.3 – Example of an Identification FunctionalGroup

This example illustrates the use of software update of several devices from the Client point of view.

This is only one example for a specific domain. There will be different Clients for different types of systems or industries (e.g., for process domain the process will not be stopped and before a sensor is updated a replacement value needs to be configured in the controller).

image064.png

Figure B.4 – Example

The example (illustrated in Figure B.4) describes a production line with several production cells. Each cell contains a robot and a main PLC that can be updated. A switch connects the cells and is also updateable via OPC UA.

A Client would perform the following steps:

  1. Analyze the system
  • Determine the network topology with all devices.
  • Determine currently installed software and how the devices can perform the update (using IVendorNameplateType Interface and Loading Object).
  • Determine technical preconditions for the update. E.g., if the device uses Direct-, Cached- or File System based Loading (using the Loading Object).
  • Prepare installation
  • The user selects the software to be installed
  • Transfer the software and firmware updates to the PLCs, the robots and the switch, except for Direct-Loading (using CachedLoadingType, FileSystem).
  • Schedule installation (Client only)
  • Determine how the update can be executed (using GetUpdateBehavior Methods of CachedLoadingType and FileSystemLoadingType).
  • Wait for strategic condition (e.g., end of shift; no task in queue).
  • Plan the order of update (e.g., robots and PLCs first; infrastructure components last).
  • Prepare devices for installation
  • Stop production line software (using an application specific Information Model).
  • Bring the robots and PLCs into a state for update (using the PrepareForUpdate state machine and/or branch specific state machine).
  • Wait for technical starting conditions (e.g., robot in standstill) (using the PrepareForUpdate state machine).
  • Execute installation
  • Start the installation of all robots and all PLCs simultaneously (using the Installation state machine).
  • Update the switch when robots & PLCs are done (using the Installation state machine).
  • Restore device state after installation
  • Restart robots and PLCs (using the PrepareForUpdate state machine and/or branch specific state machine).
  • Restart production line software (using an application specific Information Model).
  • An example sequence of Direct-Loading is shown in Figure B.5.

    If the Server does not implement the properties PrepareForUpdate, PowerCycle or Parameters of the SoftwareUpdateType, the associated options are not supported by the component and Client-Server interaction becomes simpler.

    In the first steps the device identity and the kind of supported Server options of the device must be discovered as described in Figure 34.

    How to look up and transfer files for an installation is described in Figure 35.

    The preparation can be done as described in Figure 36.

    The installation itself is described in Figure 37.

    image065.png

    Figure B.5 – Example sequence of Direct-Loading

    An example sequence of Cached-Loading is shown in Figure B.6.

    If the Server does not implement the properties PrepareForUpdate, PowerCycle or Parameters of the SoftwareUpdateType, the associated options are not supported by the component and Client-Server interaction becomes simpler.

    In the first steps the device identity and the kind of supported Server options of the device must be discovered as described in Figure 34.

    How to look up and transfer files for an installation is described in Figure 35.

    The preparation can be done as described in Figure 36.

    The installation itself is described in Figure 38.

    image066.png

    Figure B.6 – Example sequence of Cached-Loading

    An example sequence of File System based Loading is shown in Figure B.7.

    In this example the server provides the PrepareForUpdate state machine and a preparation for an installation can only be done locally at the device. So, the Resume activity described in Figure 38 cannot be commanded by a Client.

    In the first steps the device identity and the kind of supported Server options of the device must be discovered as described in Figure 34.

    How to look up and transfer files for an installation is described in Figure 35.

    The preparation can be done as described in Figure 36.

    The installation itself is described in Figure 38.

    image067.png

    Figure B.7 – Example sequence of File System based Loading