< PreviousField Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 19 of 62 Optional Optional Optional Execute PreRead Action() Select Builtin() Execute Builtin() Select PreRead Action() Execute PostRead Action() Select Builtin() Execute Builtin() Select PostRead Action() FDIClientFDIServerDevicePkg:BL Communicate to Device: Select Refresh Action() Execute Refresh Action() Process Conditionals/Relations Read Parameters Loop for all nodes in the service request Figure 8 – Online variable read If a variable has pre-read actions associated with it, these actions are executed prior to reading the variable from the device. If a variable has post-read actions associated with it, these actions are executed after reading the variable from the device. If the pre-read or post-read actions fail, the status returned for that variable shall indicate the read failed. If a variable has refresh actions associated with it, these actions are handled as in the offline variable read case (see 5.7.2). The FDI Server evaluates conditionals and relations after post-read actions are executed. This provides an opportunity for the re-evaluation of conditional expressions in EDDL Business Logic and the processing of EDDL relations. 5.8 Writing General The Write service specified in IEC 62541-4 can be used to write a single value or multiple values to a single device or multiple devices. If a Write service request specifies multiple values are to be written, the values are written in the order they appear in the service request. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 20 of 62 A failure encountered while writing a single value shall not abort the write process; all values shall be written. A status is returned indicating success or failure of each value included in the service request. Standard OPC UA service status information is returned by the FDI Server as a result of the service calls as specified in 6.2. Unlike the read operation, write failures when multiple variables are specified may leave the device in an indeterminate state with some variables modified and others left unmodified. It is up to the FDI Client to handle partial failures. FDI Clients need to lock the device for exclusive access prior to writing. The lock request may be issued immediately before the write service request or it may be issued independently across multiple write service requests (see 5.5). The FDI Server performs data validation during write service requests of online and offline values. An FDI Package can define write actions that are executed by the FDI Server during write service requests. These actions shall not require user interaction; they are strictly intended to be used for Business Logic processing. Any write action that eventually requires user interaction will not perform the built-in but will return an error if possible. The following write actions may be defined in an FDI Package: • Pre-write Actions • Post-write Actions The FDI Server invokes those actions during the processing of write service requests of online values only; they are not invoked when writing offline values. Write offline variables The sequence diagram in Figure 9 shows the behavior of the FDI Server when an offline value is written. Optional Process Conditionals/Relations FDIClientFDIServer Evaluate Lock State Write Parameters Perform Data Validation Loop for all nodes in the service request InitLock ExitLock Figure 9 – Offline variable write immediate Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 21 of 62 As a starting point for writing a variable, the FDI Server verifies if the device is locked by the FDI Client. If it is not locked, the status returned for that variable shall indicate the write failed. If the device is locked by the FDI Client, the FDI Server performs data validation. The validation consists basically of range and type check based on EDDL information. If the type validation fails, the status returned for that variable shall indicate the write failed. If the range validation fails, the status returned for that variable shall indicate the write succeeded but the status information of the variable value in the Information Model shall indicate that it is bad, out-of-range. If the validation process succeeds, the FDI Server writes to the offline value of the variable in the Information Model. After writing the variable value, the FDI Server evaluates conditionals and relations. This provides an opportunity for the re-evaluation of conditional expressions in EDDL Business Logic and the processing of EDDL relations. Writing online variables The sequence diagram in Figure 10 shows the behavior of the FDI Server when an online value is written. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 22 of 62 Optional Optional Optional Loop for all nodes in the service request Execute PreWrite Action() Select Builtin() Execute Builtin() Process Conditionals/Relations() Select PreWrite Action() Execute PostWrite Action() Select Builtin() Execute Builtin() SelectPostWriteMethod FDIClientFDIServerDevicePkg:BL Communicate to Device: Evaluate Lock State Write Parameters Perform Data Validation InitLock ExitLock Figure 10 – Online variable write immediate When writing an online variable, the FDI Server verifies if the device is locked by the FDI Client and performs data validation as described in 5.8.2. If the validation process succeeds, the FDI Server writes the variable to the physical device. If a variable has pre-write actions associated with it, these actions are executed prior to writing the variable to the device. If the pre-write actions fail, the status returned for the variable shall indicate the write failed and write operation terminates without writing to the device. If a variable has post-write actions associated with it, these actions are executed after writing the variable to the device. If the post-write actions fail, the status returned for the variable shall not indicate the write failed, since the value has already been written to the device. The status returned shall be Good_PostActionFailed. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 23 of 62 The FDI Server evaluates conditionals and relations after post-write actions are executed. This provides an opportunity for the evaluation of conditional expressions in EDDL Business Logic and the processing of EDDL relations. Writing to an EditContext The EditContext is specified in 5.6. The sequence diagram in Figure 11 shows the general behavior of an EditContext when Values are edited and applied. Loop for all edited values Optional DevicePkg:BLFDIServer Process Conditionals/Relations() FDIClient GetEditContext() Apply() Write Parameters Perform Data Validation Loop for all nodes in the service request InitLock ExitLock Edited Values that have been successfully transferred are cleared from the EditContext. If EditContext to apply is a child instance à Transfer Values to parent instance Else If Value refers to offline representation of Device à transfer data to database Else – Value refers to online representation of Device (see 5.8.3) à Execute Pre-Write Action à Communicate to Device à Execute Post-Write Action Figure 11 – Write with EditContext When writing Variables to an EditContext, the FDI Server performs data validation as in the normal writes to online or offline data. It also processes Conditionals/Relations. Changes to other Variables resulting from this process are also written to the EditContext. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 24 of 62 When calling Apply, the modified Variables are transferred to the parent. If the parent is the Device and a variable has pre-write actions associated with it, these actions are executed prior to writing the variable to the Device. If the pre-write actions fail, the status returned for Apply shall indicate the error. If the parent is the Device and a variable has post-write actions associated with it, these actions are executed after writing the variable to the Device. If the post-write actions fail, the status returned for the variable shall not indicate the write failed, since the value has already been written to the device. The status returned shall be Good_PostActionFailed. 5.9 Subscription General The Subscription service specified in IEC 62541-4 can be used to initiate the monitoring of a single variable or multiple variables from a single device or multiple devices. A failure related to a single variable while establishing a subscription to multiple variables shall not abort the subscription process; all variables shall be monitored. Each variable returned contains a status indicating success or failure. Standard OPC UA service status information is returned by the FDI Server as a result of the service calls as specified in 6.2. An FDI Package can define read actions that are executed by the FDI Server during the monitoring process of a subscription. These actions shall not require user interaction; they are strictly intended to be used for Business Logic processing. Any read action that eventually requires user interaction will not perform the built-in but will return an error if possible. The following read actions may be defined in an FDI Package: • Pre-read Actions • Post-read Actions The FDI Server invokes these actions during the monitoring of online variables only; they are not invoked when monitoring offline variables. In addition to read actions, an FDI Package can define refresh actions that are executed by the FDI Server during the monitoring process. The FDI Server invokes these refresh actions during the monitoring of both offline and online variables. These actions shall not require user interaction; they are strictly intended to be used for Business Logic processing. Any refresh action that eventually requires user interaction will not perform the built-in but will return an error if possible. The sampling interval requested by the FDI Client and established by the FDI Server defines a time interval that is used to periodically check for changes in the variables value or status. Each time interval the actions are invoked and the value and status are compared with the previous value and status. A change in the value or status will result in the FDI Server preparing a notification of the new value and status. Subscription of offline variables The sequence diagram in Figure 12 shows the behavior of the FDI Server when an offline value is being monitored. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 25 of 62 On Change Optional FDIClientFDIServerDevicePkg:BL Loop for all subscribed nodes each sampling interval Select Refresh Action() Execute Refresh Action() Process Conditionals/Relations DataChanged Notification Check Value and Status for change Subscribe Figure 12 – Offline variable subscription If a variable has refresh actions associated with it the FDI Server executes those actions each time interval. The FDI Server evaluates conditionals and relations after the refresh actions are executed. Subscription of online variables The sequence diagram in Figure 13 shows the behavior of the FDI Server when an online variable is being monitored. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 26 of 62 On Change Optional Optional Execute PreRead Action() Select Builtin() Execute Builtin() Select PreRead Action() Optional Execute PostRead Action() Select Builtin() Execute Builtin() Select PostRead Action() FDIClientFDIServerDevicePkg:BL Communicate to Device: Select Refresh Action() Execute Refresh Action() Process Conditionals/Relations DataChanged Notification Subscribe Check Value and Status for Change Loop for all subscribed nodes each sampling interval Figure 13 – Online variable subscription The variable is read from the device each time interval. If a variable has pre-read actions associated with it, these actions are executed prior to reading the variable from the device. If a variable has post-read actions associated with it, these actions are executed after reading the variable from the device. If a variable has refresh actions associated with it the FDI Server executes those actions after the post-read actions. The FDI Server evaluates conditionals and relations after any associated actions are executed. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 27 of 62 If the actions fail or the device read fails, the status of the variable shall indicate the failure. 5.10 Device topology General The FDI Server maintains Device Instances in the Information Model. The Information Model maintained by the FDI Server reflects the structure of the system; the FDI Server maintains device information in the context of the Device Topology. The Device Topology includes devices, connecting communication networks, and the elements to communicate via these networks. The Device Topology is defined in FCG TS62769-5; Objects, References and the AddressSpace organization required to create the proper Information Model are defined as part of the Information Model specification. Connection Points The following non-normative Figure 14 illustrates the topology within the Information Model. DeviceType FI B101 Network_B CP_B1 CP_B2 DeviceType FI B102 <some>DeviceType: Master CP_Master ConnectionPoint Type Figure 14 – Topology with Network objects (non-normative) The FDI Server uses the information in the FDI Package to create both the type definitions for the devices and Communication Devices as well as their respective Connection Point elements. The mapping between the FDI Package definition and the Information Model elements is defined in FCG TS62769-5. Network types for the protocols that are supported by Native Communication devices are provided by the FDI Server. Network types for non-native protocols are provided through FDI Package definitions provided for the communication server. Device definitions contain one or more Connection Point definitions for a device. Each Connection Point maintains a reference to a protocol element that specifies the protocol for the Connection Point. A device may be capable of providing or using multiple protocols; each protocol provided or supported will have a unique Connection Point. The network objects contain a reference to a protocol definition element that defines the protocol utilized by the network object. The Device and Connection Point type definitions are used to create Device and Connection Point instances. The network type definitions are used to create instances of networks in the system. The network types are specified in the protocol specific annexes in FCG TS62769-4, and are provided by the FDI Server as an integral component. The FDI Server, or FDI Clients Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 28 of 62 interacting with the FDI Server to create the topology, locates devices, communication devices, connection points, and networks using standard OPC UA entry points for browsing: • DeviceSet – references Device Instances in the FDI Server. • CommunicationSet – references instances of communication devices in the FDI Server. • NetworkSet – references instances of networks in the FDI Server. The FDI Server, or FDI Clients interacting with the FDI Server to create the topology, creates references between instances of a device, an associated Connection Point, and a network element (see Figure 14). The FDI Server validates that the protocol associated with the Connection Point and the protocol associated with the network are of the same protocol type. If a device defines multiple Connection Points, the FDI Server will use the Connection Point of the device that matches the network protocol. Each network object shall be associated with at least one Communication Device. The association between the communication device and the network element shall be done before devices can be associated with the network element. Once a Communication Device is associated with a network element, Business Logic in the Communication Device will be used for network management. The network element definition specifies the number of Connection Points that can be added to the network. The references established between devices, Connection Points, and networks do not affect the reference established for the standard browse entry points. Devices remain referenced by DeviceSet regardless of whether the device has a reference to a Connection Point or to a network. Topology management 5.10.3.1 General FDI Server vendors have two options to provide trusted FDI Clients with the ability to manage the topology: a) they may provide vendor specific functionality; b) they may implement the OPC UA NodeManagement Service Set. If the FDI Server vendor chooses the second option, i.e., implementing the OPC UA NodeManagement Service Set, the topology management shall be implemented as specified in 5.10.3. In order to prevent simultaneous access from different agents that are trying to modify the topology, the elements involved in the topology modification are locked. The scope of the lock for Modular Devices and networks is specified in FCG TS62769-5. The FDI Package for the Communication Device includes definitions that are used by the FDI Server to manage and validate the topology, including the optional action ValidateNetwork (see FCG TS62769-7). Those definitions are used by the FDI Server during topology management. 5.10.3.2 Add Device to Network The sequence diagram in Figure 15 shows the behavior of the FDI Server when a device is added to a network. Next >