< PreviousField Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 29 of 62 Optional Optional Optional Select Builtin() Object Reference() Loop for all nodes in the service request Notification Message(event) Update Server Information Model() FDIClientFDIServerCommDevicePkg:BL Create Working Copy: Loop for all nodes in the Working Copy Working Copy deleted: Object Reference (child) Perform Validation() Select ValidateNetwork Action() Execute ValidateNetwork Action() InitLock() EnterEditMode() AddReferences() Validate Connectivity() ValidateNetwork = OK ExitEditMode() ExitLock() Figure 15 – Add Device to topology The AddReferences service specified in IEC 62541-4 is used to add devices to the topology. The AddReferences service can be used to establish a single or multiple references. If an AddReferences service request specifies multiple references are to be added, the references are added in the order they appear in the service request. A failure encountered while adding a single reference shall not abort the entire process; all references shall be processed. A status is returned indicating success or failure for each reference 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. When adding a reference, the association of a device’s Connection Point with a network shall be validated by the FDI Server; this applies to both FDI Server vendor specific topology management as well as the OPC UA AddNode method. The FDI Server performs an initial validation of the connectivity, which includes for instance verifying that the protocol specified by the Connection Point and the network are the same and the number of connections supported by the network have not been exceeded. That validation is based on information provided with the FDI Communication Package of the involved elements. If the initial validation succeeds, the ValidateNetwork Action provided by the Communication Device is invoked by the FDI Server. See FCG TS62769-7 for more details. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 30 of 62 In a first pass, all requested references are added regardless of the validation process succeeding or failing. After adding all references, a second validation pass is done. If the validation process fails for any reference, that reference shall not be added and the status returned for that reference shall indicate the reference failed to be added. Because of this two-step validation process performed by the FDI Server, the result of adding multiple references at a time can be different from the result of adding one reference at a time. 5.10.3.3 Remove Device from Network The sequence diagram in Figure 16 shows the behavior of the FDI Server when a device is removed from a network. Optional Optional Optional Select Builtin() Object Reference() Loop for all nodes in the service request Notification Message(event) Update Server Information Model() FDIClientFDIServerCommDevicePkg:BL Create Working Copy: Loop for all nodes in the Working Copy Working Copy deleted: Object Reference (child) Perform Validation() Select ValidateNetwork Action() Execute ValidateNetwork Action() InitLock() EnterEditMode() DeleteReferences() ValidateNetwork = OK ExitEditMode() ExitLock() Figure 16 – Remove Device from topology The DeleteReferences service specified in -4 is used to remove devices from the topology. The DeleteReferences service can be used to remove a single reference or multiple references. If a DeleteReferences service request specifies multiple references are to be removed, the references are removed in the order they appear in the service request. A failure encountered while removing a single reference shall not abort the entire process; all references shall be processed. A status is returned indicating success or failure for each reference included in the service Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 31 of 62 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. The removal of a device from a network requires the FDI Server to validate the network. The FDI Server invokes the ValidateNetwork Action provided by the Communication Device after removal of the device from the network. In a first pass, all requested references are removed regardless of the validation process succeeding or failing. After removing all references, a second validation pass is done. If the validation process fails for any reference, that reference shall not be removed and the status returned for that reference shall indicate the reference failed to be removed. Because of this two-step validation process performed by the FDI Server, the result of adding multiple references at a time can be different from the result of adding one reference at a time. Topology scanning The sequence diagram in Figure 17 shows the behavior of the FDI Server when the topology is scanned. Execute SCAN Action() Select Builtin() Execute Builtin (send_command/send_value) Select SCAN Action() Generate scan list XML() FDIClientFDIServer DevicePkg:BL (Interface) Invoke Method (scan) Create SCANLIST() Get SCANLIST variable() Invoke Method (scan) Perform Access Calls as needed Figure 17 – Scan topology Scanning of a network for connected devices is provided via the Scan Service associated with Communication Devices. This service is described in FCG TS62769-5. For nodes representing Native Communication devices, the FDI Server provides the service implementation. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 32 of 62 For Communication Devices that are not native to the FDI Server, the FDI Server invokes the SCAN Action provided by the Communication Device (see FCG TS62769-4). The SCAN action invokes built-ins provided by the FDI Server to send commands to the Communication Device. The SCAN action processes the responses to the commands to create a scan list. The scan list created by the SCAN Action is stored in a DDLIST variable referenced through the SCAN_LIST variable. The DDLIST contains the definition for the devices detected by the communication device. The Information Model specified in FCG TS62769-5 provides protocol independent definitions for devices. The protocol independent device definitions contain references to nodes containing protocol specific identification for a device. The DDLIST variable resulting from the scan is composed of variable definitions. The DDLIST will contain variables whose name matches the properties and attributes defined in FCG TS62769-5 for the protocol independent device definition. These protocol independent definitions allow the FDI Server to formulate protocol independent information to an FDI Client about the devices in the network. The SCAN Action may not fully identify a device; variables providing protocol independent information may be missing from the DDLIST. The FDI Server through vendor specific functions performs additional parameter read and write actions to the device to complete the identification. This functionality is both FDI Server vendor specific as well as protocol specific and is not standardized. The DDLIST also contains network addressing information for the devices identified in the network. The network addressing will be protocol specific but match the protocol specific Connection Point properties and attributes specified in FCG TS62769-5. The DDLIST may also contain additional variables that are protocol specific. The protocol specific variables are standardized by the foundations defining the network protocol, see protocol specific annexes in FCG TS62769-4. The FDI Server is responsible for the creation of the XML data set returned by the Scan Service using the information provided by the DDLIST variable. Use of SCAN function The SCAN function can be used by the FDI Server as part of topology management. The FDI Server vendor specific functions for topology management may perform network SCANS to define the Device Instances to create and to initialize the Information Model topology. The SCAN function is provided by communication devices; a device definition does not have to exist in the Information Model for the SCAN function to succeed. The information provided by the SCAN function may be used by FDI Server vendor specific functionality to create the Device Topology. FDI Server vendor specific functionality is responsible for matching the devices identified by the SCAN function to device types in the Information Model. The FDI Server, through vendor specific implementation, uses the SCAN function as part of commissioning a network. The FDI Server vendor specific implementation allows the FDI Server to match and validate the offline created topology against the physical network (see 5.10.6). The use of the SCAN function for topology creation and topology validation is not standardized and is an FDI Server vendor specific functionality. Validation of defined topology The FDI Server shall validate that the defined Device Instance in the Information Model matches the physical device. FDI Server vendor specific functionality is responsible for validating the Information Model against the physical devices connected in the system. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 33 of 62 The FDI Server can rely on standard functions such as SCAN to identify the devices physically connected and determine whether there is a match with the offline defined topology. The FDI Server may also use protocol specific commands to identify devices. The FDI Server shall validate that the physical device is of the same type as the Device Instance in the Information Model. FDI Server vendor specific implementations can allow connectivity to devices of different revisions or require an exact match. FDI Server vendor specific functionality provides the device matching. 5.11 User Interface Elements User Interface Descriptions User Interface Descriptions (UIDs) are descriptive user interfaces that are rendered by an FDI Client. They appear in the Information Model as UIDescriptionType nodes (see FCG TS62769-5). FDI Clients retrieve UIDs by reading the Value attribute of a UIDescriptionType node in the Information Model. The Value attribute of a UIDescriptionType node contains the UID in the form of an XML string (see FCG TS62769-2). Any values that the FDI Server provides to the FDI Client through the UID shall be unscaled, including, for instance, current variable values, ranges and initial values. FDI Servers shall evaluate any conditional behavior present in a UID before providing it to the FDI Client. The FDI Client shall simply render the UID provided by the FDI Server. This example assumes the UID is based on EDDL. If the PATH attribute of an IMAGE is conditional (i.e., dependent on the value of a parameter in the device), the FDI Server shall evaluate the conditional to determine which image is to be used and then provide the appropriate Browse Name to the FDI Client via the XML string. The FDI Client will simply render the appropriate image. All other EDDL conditionals shall be evaluated by the FDI Server in a similar fashion. An FDI Package can define actions that are associated with UIDs. The following actions may be defined in an FDI Package: • Pre-edit Actions • Post-edit Actions • Init Actions • Refresh Actions • Exit Actions Those actions are executed by the FDI Server, but their execution is driven by the FDI Client. In order to allow the FDI Client to drive the execution of actions, the FDI Server creates Actions Proxies (see 5.12.3) and makes the Action Proxies names available to the FDI Client by means of the ListOfActions element type defined in the XML schema (FCG TS62769-2). The FDI Server thus maintains the Actions Proxies names in the XML string of the UID. As the FDI Client retrieves UIDs, it retrieves the Actions Proxies names associated to them as well. Even though a single EDD Actions definition may specify more than one EDD Method, the FDI Server does not provide individual references to each EDD Method that is specified, but it provides a single Actions Proxy name to refer to all EDD Methods specified in the EDD Actions clause. As a consequence, the list of actions specified in the XML schema will always have a single entry. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 34 of 62 As the FDI Client processes a UID, it can start the execution of actions by calling the InvokeAction service and passing the corresponding Actions Proxy name as argument (see 5.12.3). User Interface Plug-ins User Interface Plug-ins (UIPs) are programmatic user interfaces that are executed by an FDI Client. They appear in the Information Model as UIPluginType nodes (see FCG TS62769-5). FDI Clients retrieve UIPs by reading the Value attribute of a UIPluginType node in the Information Model. The Value attribute of a UIPluginType node is a byte array containing a binary executable component (seeFCG TS62769-5). FDI Packages can provide multiple variants of the same UIP (see FCG TS62769-4). FDI Clients browse through the available UIP Variants and select the variant that is most appropriate. Unlike UIDs, UIPs are not processed by an FDI Server in any way; they are imported from the FDI Package and simply provided to the FDI Client upon request. FDI Device Packages can reference a UIP in a separate FDI UIP Package (see FCG TS62769-4). FDI Servers shall resolve these references. Any references that cannot be resolved shall result in a Bad_NodeIdUnknown status code when the UIP is read by an FDI Client. 5.12 Actions FDI Server – FDI Client interaction FDI Clients invoke Actions by calling the InvokeAction method (see FCG TS62769-5). When an Action is invoked the FDI Server creates a state machine that is maintained while the Action is executing. The state may change in response to the built-in functions that are invoked by the Action, as well as in response to interactions with the FDI Client. The FDI Server then creates a transient, non-browsable Variable in the Information Model for the exchange of information between the FDI Server and the FDI Client, henceforth referred to as the exchange variable. The NodeId of the exchange variable is returned to the FDI Client as an output argument of the InvokeAction method (see FCG TS62769-5). Once the state machine has been created, the exchange variables have been created, and the Action has started to execute, the InvokeAction method terminates, i.e., it does not remain active during the execution of the Action. The FDI Server sends user interface requests to the FDI Client via the exchange variable, and the FDI Client sends user interface responses to the FDI Server via the exchange variable. The value of the exchange variable is an XML string (see FCG TS62769-2). It contains the current state of the Action, as well as a user interface request or response. The subscription service specified in IEC 62541-4 is used to allow the FDI Server to send user interface requests to the FDI Client via the exchange variable. The FDI Client subscribes to the exchange variable to receive user interface requests from the FDI Server. If a request is transitional the FDI Client may miss the request. The request will be held in the exchange variable until the FDI Client creates a subscription. Once the subscription is established, the FDI Server will respond with the current state and the pending request. NOTE 1 TimeDelay with a short duration is an example of a transitional request. The FDI Server can implement a server-defined time-out for user interface requests. Failure of the FDI Client to respond to a user interface request before the time-out expires can cause the FDI Server to abort the Action. NOTE 2 The time-out is expected to be on the order of 20 min to 30 min similar to a session time-out of a web page. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 35 of 62 The FDI Server retains the current state and the last request in the exchange variable even after the Action completes. The exchange variable retains its value until the FDI Client terminates the subscription. An Action can be aborted by the FDI Client or by the Action itself. The sequence diagram shown in Figure 18 shows the client/server interaction of an Action. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 36 of 62 FDI ClientFDI ServerDevicePkg:Action Call InvokeAction ("action name", argument list) Create UIDDescriptionType Variable argument list: Execute Action "action name" Initialize state management Return nodeID for UIDDescriptionType Variable Action Specific processing – multiple requests processed SelectBuiltinMethod ExecuteBuiltinMethod Create UIDDescriptionType state update Create Subscription Create Subscription Create Monitored Item : UID DescriptionType variable Create Monitored Item Update UIDDescriptionType Variable Update Monitored Item UID DescriptionType Update State Wait for UIDDescriptionType response Write UIDDescriptionType Variable - Response Update State UI Response Update State to Action Complete Update Monitored Item - UIDDescriptionType Create UIDDescriptionType request Update UIDDescriptionType Variable Subscription creation and monitored item creation processing specific to client Subscription deletion and monitored item deletion processing specific to client Delete Monitored Item Delete Subscription Delete state management Delete UIDDescriptionType Variable Message1 Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 37 of 62 Figure 18 – Action execution Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 38 of 62 Action state machine 5.12.2.1 States The Action state machine is shown in Figure 19. Created Running WaitingForFeedback TimeDelay Completed Aborting TimeDelayA Aborted WaitingForFeedbackA Figure 19 – Action state machine The states of the Action state machine are specified in Table 1. Table 1 – Action states State Description Created The initial state when the state machine instance is created by the FDI Server. Running The normal execution state. TimeDelay The state where the normal execution is suspended a certain amount of time. WaitingForFeedback The state where the normal execution is suspended because a user interaction is needed. Aborting The state where the normal execution has been aborted and abort processing is carried out. TimeDelayA The state where the abort processing is suspended a certain amount of time. WaitingForFeedbackA The state where the abort processing is suspended because a user interaction is needed. Completed The state where the normal execution is completed. Aborted The state where the abort processing is completed. Next >