< PreviousField Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 39 of 62 5.12.2.2 State transitions The state transitions of the Action state machine are defined in Table 2. Table 2 – Action state transitions Source state Event Destination state Start State FDI Server created a state machine for the Action. Created Created Execution of the Action has started. Running Running Execution of the Action has completed. Completed Running Built-in function has been encountered that requires a time delay. TimeDelay Running Built-in function has been encountered that requires user feedback. WaitingForFeedback Running Abnormal termination of the Action has been initiated by either the FDI Server or the FDI Client. Aborting TimeDelay FDI Server has decided to send time delay remaining to FDI Client. TimeDelay TimeDelay FDI Server has calculated a new time delay to be sent to FDI Client. TimeDelay TimeDelay Abnormal termination of the Action has been initiated by the FDI Client. Aborting TimeDelay Delay time has expired. Running WaitingForFeedback FDI Server has decided to send an updated feedback request to the FDI Client. WaitingForFeedback WaitingForFeedback FDI Server has received feedback from FDI Client. Running WaitingForFeedback Abnormal termination of the Action has been initiated by either the FDI Server or the FDI Client. Aborting WaitingForFeedback FDI Server timeout period has expired with no response from FDI Client. Aborting Aborting Built-in function has been encountered that requires a time delay. TimeDelayA Aborting Built-in function has been encountered that requires user feedback. WaitingForFeedbackA Aborting Execution of the Action has completed. Aborted TimeDelayA Delay time has expired. Aborting WaitingForFeedbackA FDI Server has decided to send an updated feedback request to the FDI Client. WaitingForFeedbackA WaitingForFeedbackA FDI Server has received feedback from FDI Client. Aborting Aborted FDI Server has destroyed the state machine for the Action. Finish State Completed FDI Server has destroyed the state machine for the Action. Finish State Actions Proxies EDD Actions specify EDD Methods that shall be executed at specific moments during the processing of variable values or during user interaction. In many cases, the FDI Server implicitly executes the EDD Actions, but in some specific cases, as specified in 5.12.4, the execution of EDD Actions is driven by the FDI Client. In order to allow the FDI Client to drive the execution of EDD Actions, the FDI Server creates Actions Proxies. An Actions Proxy is an internal entity created by the FDI Server to encapsulate the EDD Methods specified in the EDD Action definition. An Actions Proxy thus corresponds to a single “*_ACTIONS” clause in EDDL and therefore to the entire set of EDD Methods specified in it. The FDI Server assigns a name to the Actions Proxy. The Actions Proxy name is an unambiguous identifier, i.e., it uniquely identifies the Actions Proxy in the scope of a single device instance. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 40 of 62 The FDI Server makes the Actions Proxy name available to the FDI Client via the XML descriptions associated to UID nodes (see 5.11.1). The FDI Client can thus drive the execution of an Actions Proxy when necessary by calling the InvokeAction method and passing the Actions Proxy name as argument. NOTE The second argument of the InvokeAction method (“MethodArguments”) is empty, since EDD Actions have no arguments. When processing an InvokeAction call with an Actions Proxy name as argument, the FDI Server executes the entire set of EDD Methods associated to that Actions Proxy. As specified in FCG TS61804-3, the FDI Server executes those EDD Methods in the order they appear in the EDD Action definition, and if an EDD Method exits for an unplanned reason, the following EDD Methods are not executed. Taking as reference the state transitions defined in Table 2, it means that: • the state machine transitions from the state “Created” to the state “Running” when the execution of the first EDD Method in the Actions Proxy definition starts; • in the mean time between the execution of two EDD Methods the state machine remains in the state “Running”; • the state machine only transitions from the state “Running” to the state “Completed” when the execution of the last EDD Method in the Actions Proxy definition completes, or if any EDD Method exits for an unplanned reason. All other state transitions remain the same. Actions, EDD Actions and Actions Proxies Actions are a provision of the FDI Server to allow FDI Clients to execute both EDD Methods in general and EDD Actions in particular. EDD Methods in general, with the exception of abort and action methods, are exposed in the Information Model as nodes under the ActionSet Object of the corresponding device or block node (see FCG TS62769-5). EDD Actions on the other hand are not exposed in the Information Model. EDD Actions are made available to the FDI Client by putting the names of their corresponding Actions Proxies in the ListOfActions element in the XML description of the UID nodes (see 5.11.1). The EDD Action types and the EDD constructs that use them are shown in Table 3 (see FCG TS61804-3). Table 3 – EDD Action types and the EDD constructs that use them EDD Action type EDD construct UID VARIABLE MENU EDIT_DISPLAY WAVEFORM SOURCE Pre-read Actions I I Post-read Actions I I Pre-write Actions I I Post-write Actions I I Pre-edit Actions E E E E Post-edit Actions E E E E Init Actions E E E E Exit Actions E E E E Refresh Actions I E E E E As Table 3 indicates, in some cases the FDI Server implicitly executes the EDD Actions (I), while in other cases the execution of EDD Actions is driven by the FDI Client, i.e., the FDI Client needs to explicitly start the execution of the EDD Actions in the FDI Server (E). The FDI Server implicitly executes the following types of EDD Actions: • Pre-read, post-read, pre-write and post-write actions, both for variables and menus. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 41 of 62 • Refresh actions for variables. Those types of actions shall not require user interaction; they are strictly intended to be used for Business Logic processing. Any action of one of those types that eventually requires user interaction will not perform the built- in but will return an error if possible. The FDI Server implicitly handles pre-read, post-read and refresh actions for variables when the FDI Client reads online variables (see 5.7.3). Similarly, the FDI Server implicitly handles pre-write and post-write actions for variables when the FDI Client writes online variables, either in an immediate fashion (see 5.8.3) or in edit mode (see 5.8.4). The pre-read, post-read, pre-write and post-write actions for menus are only used by the upload and download menus (see FCG TS61804-4 and FCG TS62769-2). The FDI Server implicitly handles pre-write and post-write actions for menus when the FDI Client transfers data to the device (5.2.2). Similarly, the FDI Server implicitly handles pre-read and post-read actions for menus when the FDI Client transfers data from the device (5.2.3). The FDI Client explicitly starts the execution of the following types of EDD Actions: • Pre-edit and post-edit actions for variables, menus, edit-displays and UIDs. • Init, exit and refresh actions for menus, waveforms, sources and UIDs. When those actions contain user interactions (see FCG TS61804-4), they will require interaction between the FDI Server and the FDI Client. This is achieved by using Actions, as specified in 5.12.1. The FDI Client explicitly starts the execution of those types of actions in the FDI Server by calling the InvokeAction method and passing the name of the corresponding Actions Proxy as argument. 6 OPC UA services 6.1 OPC UA profiles The set of services specified for OPC UA are grouped into standardized profiles as defined in IEC 62541-7. FDI Servers shall conform to the FDI Server Profile, which is specified as: • including OPC UA "Standard Server" • including OPC UA "DataAccess Server Facet" • including OPC UA "Node Management Server Facet" • including OPC UA "Method Server Facet" • including OPC UA "Event Subscription Server Facet" • including OPC UA "Auditing Server Facet" • including FDI "FDI Information Model" 6.2 Service error information Overview FDI Servers provide service operations that are invoked through OPC UA services. Standard OPC UA service status information is returned by the FDI Server as a result of the service calls. The OPC UA specification defines all services as having a standard response that includes a response header containing general and service specific response codes according to IEC 62541-4. The response code structure contains diagnostic information that returns both an error code as well as localized text for the error. FDI Servers shall fill in the diagnostic records including localized text for the reported errors. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 42 of 62 The OPC UA diagnostic record allows Servers to include “inner” status information. FDI Servers will provide technology binding specific errors in the “inner” status record. OPC UA services and their response When the FDI Client submits a Service request Message to the FDI Server, if the service is supported and executed, the FDI Server generates a success/failure code that it includes in a positive response Message along with any data that is to be returned. Each Service request has a RequestHeader and each Service response has a ResponseHeader. The ResponseHeader is a structure that has data members used to convey EDDL diagnostics information, the serviceResult and the diagnosticInfo. The serviceResult is the standard, OPC UA-defined result of the Service invocation. The serviceResult type is StatusCode, which defines a standard numerical value that is used to report the outcome of an operation performed by an FDI Server. This code may have associated diagnostic information that describes the status in more detail. The diagnosticInfo is a structure that is intended to return vendor-specific diagnostic information. Mappings of EDDL response codes to OPC UA service response When FDI Clients use OPC UA services to read and write the Attributes of Parameters they receive back as part of the FDI Server response a ResponseHeader with success/failure code and diagnostics information. The FDI Server uses the serviceResult and the diagnosticInfo data members of the ResponseHeader to return error and diagnostics information related to failure of execution of EDDL variable actions, including PRE_READ, POST_READ, PRE_WRITE and POST_WRITE actions. The StatusCode returned in the serviceResult data member of the ResponseHeader is also used to handle the EDDL VALIDITY attribute. Any attempt to access an invalid variable will be reported to the FDI Client as the result of a service call. The service returns a “Bad Failure” in the Severity bit of the StatusCode. In addition, the diagnosticInfo data member of the ResponseHeader can be used to provide detailed diagnostics on the failure. The FDI Server shall also deal with the fact that VALIDITY can be the result of the evaluation of a conditional expression. In that case, FDI Clients rely on the FDI Server notification capabilities when the model dynamically changes due to a conditional evaluation. The serviceResult and the diagnosticInfo data members of the ResponseHeader are used to return error and diagnostics information related to EDDL response codes. EDDL response codes specify values that a device may return as the result of an operation. Each EDDL variable, record or value array can define its own associated set of response codes. The serviceResult is used to return a status that corresponds to the EDDL response code TYPE attribute. The Severity bits of the StatusCode are set based on the response code TYPE according to Table 4. Table 4 – OPC UA severity bits and EDDL response codes TYPE OPC UA Severity EDDL Response Codes Type Good Success SUCCESS Uncertain Warning MISC_WARNING, DATA_ENTRY_WARNING Bad Failure DATA_ENTRY_ERROR, MODE_ERROR, PROCESS_ERROR, MISC_ERROR The symbolicIdIndex, localizedTextIndex and the additionalInfo data members of the diagnosticInfo are used to return the response code and the text description gotten from EDDL response codes definitions. It is the FDI Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 43 of 62 Server’s responsibility to translate the integer response code into its corresponding text description and fill in the diagnosticInfo. The symbolicIdIndex data member is used to return the numeric response code from the EDDL RESPONSE_CODE. The numeric code shall be converted into a string in the stringTable. The symbolicIdIndex contains the index into the stringTable. The localizedTextIndex data member is used to return the DESCRIPTION attribute from the EDDL RESPONSE_CODE. The DESCRIPTION string is conveyed to the FDI Client in the stringTable data member of the ResponseHeader parameter. The localizedTextIndex contains the index into the stringTable. The additionalInfo data member is used to return the HELP attribute from the EDDL RESPONSE_CODE. In addition to the response codes described via EDDL, standard response codes defined by the underlying communication protocols may also be returned. 6.3 Parameter value update during write service request The FDI Server maintains an Information Model that contains Online variables that cache the value of the device variables. The specified behavior for OPC UA is for the Server to only store in the Online Variables those values that the Server has read from the device. The FDI Server is not allowed, according to OPC UA specified behavior, to write a value both to the device and to the Online variable. 6.4 Localization The Information Model defined for FDI, FCG TS62769-5, is based on OPC UA. The OPC UA specification defines descriptive attributes and properties of elements to be localized strings. The FDI Server provides localized information for the OPC UA specified localized attributes and properties in the Device Type and Device Instance nodes. The FDI Server uses information provided by the descriptive component in the FDI Package for a device type to create localized strings. FDI Packages support the specification of localized strings for descriptive information. If the device vendor provides such information, the FDI Server uses the appropriate localized string as the value for device type attributes and properties when responding to an FDI Client. If the descriptive element in the FDI Package does not provide localized information, either no information or no information for the requested locale, the FDI Server will return the English default string. Multiple clients connecting at the same time may eventually request the FDI Server to return localized attributes and properties in different languages. The FDI Server shall support multiple languages simultaneously when the clients requesting different languages connect to different Device Type or Device Instance nodes. When clients requesting different languages connect at the same time to the same Device Type or Device Instance node, the support to multiple languages is optional. If the FDI Server does not support multiple languages in that situation, then it shall implement a “first wins” solution, i.e., it will use the language requested by the first client that connected to the Device Type or Device Instance node when returning localized attributes and properties to all subsequent clients. 6.5 Audit events FDI Servers shall provide support for vendor specific audit trail functionality. The support for auditing in the FDI Server is specified in FCG TS62769-5. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 44 of 62 7 Communication 7.1 Notation Clause 7 describing communication contains diagrams showing the Information Model, FCG TS62769-5. The notation used in these figures uses the standards defined by OPC UA. These standards are summarized in FCG TS62769-5. 7.2 General Concepts The FDI Server is responsible for managing communications. The FDI Server can support three types of communication infrastructure components: • System communication hardware (see Figure 1) • FDI Communication Server • Communication gateways (Nested Communication) The FDI Server can support system specific communication hardware (see Figure 1). The FDI Server interacts with the driver of the system communication hardware through proprietary interfaces to process fieldbus communication. System specific communication management is not in the FDI specification scope. Figure 20 shows a possible architecture example of system communication integration. System CommunicationFDI Server Information Model NetworkType: Network_B ConnectionPointType: CP_B2 ConnectionPointType: CP_B1 DeviceType: FI B101 DeviceType: FI B102 Communication Services Hardware Driver PHY FI B101 Network B Communication Relation Figure 20 – System communication integration example The FDI Server can implement access to physical networks through FDI Communication Servers (see Figure 1) (FCG TS62769-7). The FDI Communication Server implements the access to the physical network. The interface between the FDI Server and the FDI Communication Server is based on OPC UA. The FDI Communication Server implements the OPC UA Server function. The FDI Server implements the OPC UA Client function. The FDI Communication Server implemented Information Model enables the access to the communication services. An FDI Communication Server integration example is shown in Figure 21. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 45 of 62 FDI Communication Server FDI Server Information Model ServerCommunicationDeviceType : CommunicationDeviceName ConnectionPointType: CP_B_Master NetworkType: Network_B ConnectionPointType: CP_B2 ConnectionPointType: CP_B1 DeviceType: FI B101 DeviceType: FI B102 Communication Relation OPC UA Communication Services Hardware Driver PHY FI B101 Network B ServerCommunicationServiceType: CommunicationServiceProvider_B CommunicationServerType: CommunicationServerName SubDevices Figure 21 – FDI Communication Server integration example In terms of the Information Model structure the system communication hardware and the FDI Communication Server represent root communication devices. FDI supports Nested Communication. The term “Nested Communication” stands for the ability of a system to process communication across protocol boundaries in heterogeneous networks. The insertion of additional communication gateway devices into the topology as shown in Figure 22 enables the handling of heterogeneous networks. These communication gateway devices implement the bridging functionally between different networks (gateway firmware). The gateway firmware implemented bridging functionality is also implemented in the Business Logic provided with the FDI Package describing the communication gateway. The FDI Server interacts only with this Business Logic of the communication gateway to process the Nested Communication function. A communication gateway integration example is shown in Figure 22. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 46 of 62 FDI Communication Server FDI Server Information Model ServerCommunicationDeviceType : Network_B_Channel ConnectionPointType: CP_B_Master NetworkType: Network_B ConnectionPointType: CP_B1 DeviceType: FI G101 OPC UA Communication Services Hardware Driver PHY Communication Relation GatewayCommunicationDeviceType : Module 1 CommunicationGatewayType : Gateway_B1 ConnectionPointType: CP_G_Module NetworkType: Network_G ConnectionPointType: CP_G1 Gateway_B1 Module 1 Module 2 Module n FI G101 Network B Network G [1..n] CommunicationServerType: CommunicationServerName SubDevices SubDevices ServerCommunicationServiceType: CommunicationServiceProvider_B GatewayCommunicationServiceType: CommunicationServiceProvider_G Figure 22 – Gateway integration example Terms The following contains a list of terms used in 7.3: 1) A Connection Point is an instance of a ConnectionPointType (FCG TS62769-5). 2) A Device is an instance of a DeviceType. 3) A Connection Point associated to a Device is called Device Connection Point. 4) A Connection Point associated to a Communication Device is called Communication Device Connection Point. 5) A Network is an instance of NetworkType (FCG TS62769-5). 6) FDI Communication Server (FCG TS62769-7). Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 47 of 62 7.3 Communication Service processing Communication Service invocation FCG TS62769-7 specifies that both Gateways and FDI Communication Servers implement the communication services. Those services are specified in FCG TS62769-7. In order to allow the flexibility that is necessary to represent a variety of different scenarios involving communication between the communication server and the physical devices, FCG TS62769-7 specifies that some communication services are provided through a communication service provider. While the communication service provider allows multitasking and enhances the communication capabilities of a communication device, it requires parallel execution in the server. The details about communication service providers (ServerCommunicationServiceType and GatewayCommunicationServiceType) are specified in FCG TS62769-7. The requirements for parallel execution in the service are described through the rules stated in Clause 8. The difference between a Gateway and an FDI Communication Server is about how or where these services shall be invoked: a) If the communication device is an FDI Communication Server, the FDI Server invokes a communication service directly at the FDI Communication Server using an OPC UA Method service Call specified in IEC 62541-4. This call will end up in actual fieldbus communication. b) If the communication device is part of a Gateway, the FDI Server invokes the communication service in terms of invoking an Action implemented by the Business Logic of the specific Gateway. The behavior (reaction) of the Gateway Business Logic is described in FCG TS62769-7. Analyze communication path The Information Model defined in FCG TS62769-5 supports a hierarchical topology. As shown in Figure 22 the topology reflects the physical network topology. The communication path analysis function allows the FDI Server to determine how communication messages need to be propagated from the Device that triggered a communication request to the Communication Device implementing the network access (root communication device) and which communication relations need to be activated before. Subsequent text will only consider the root communication device based on the FDI Communication Server. The FDI Server identifies the communication path between a Device and an FDI Communication Server according to the following rules: a) Topology iteration starts from the node representing the Device passing the elements Device Connection Point, Network, Communication Device Connection Point to the Communication Device within the same Network hierarchy. In this way, the FDI Server determines the local communication relation. A Communication Device that is associated next to the Device implements the communication service provider for this Device, this means the FDI Server shall propagate the communication service request between the Device and Communication Service Provider. b) The FDI Server identifies a communication gateway along its Information Model structure as demonstrated in Figure 22. The key indicators are the Communication Device organized below a Device using the “has Component” relation. This specific device is called Gateway Head Station, which is connected to a different Network via a Connection Point. From here, the iteration continues as described in a). c) The topology iteration procedure ends with finding the communication root device. The FDI Server identifies an FDI Communication Server (communication root device) because it has no association to other networks than the network for which the FDI Communication Server implements the communication service provider. NOTE How the FDI Server determines System Communication Device is out of the scope of this standard. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 48 of 62 Manage communication relations Prior to any data exchange related transfers the FDI Server needs to establish or activate the communication relation between the Device representations in the Information Model and the physical network connected device. The invocation sequence of the communication service Connect on any of the Communication Devices along the communication path shall begin with the root communication device. The communication service Connect is specified in FCG TS62769-7. The Device Connection Point contains the address information to be used for the Connect service. The Information Model element FunctionalGroupType:Identification contains optionally required protocol specific device type identification data. The Connect service argument names shall match with the browse names of the Information Model elements that hold related values (browse name matching). The successful execution of service Connect activates the local communication relation between a Device and a Communication Device associated to the same network. The successful execution of service Connect on a network higher in a hierarchy is a prerequisite to a successful execution of the service Connect on a network lower in the hierarchy. The reason for this is the Gateway Business Logic that can invoke other communication services requiring an activated communication relation. The FDI Server manages a CommunicationRelationId according to FCG TS62769-7. A connection abort indication or the invocation of service Disconnect as described in FCG TS62769-7 deactivates the local communication relation and any of the local communication relations in networks lower in the hierarchy. Communication service request mapping The FDI Server receives communication service requests from Devices or Gateways through: a) the Online Variable Read b) the Online Variable Write c) the Business Logic invoking the communication related EDDL Built-In function, for example, send, send_all_values, send_command, send_command_trans, send_trans, send_value, WRITE_COMMAND, READ_COMMAND, and so on. Like the Device all of these communication service requests related source events apply to the EDDL PROFILE (FCG TS61804-3). The FDI Server shall handle the communication service requests according to EDDL defined PROFILEs. Since the EDDs shipped with the FDI Packages can describe relations between VARIABLE elements and COMMAND elements, the Variable Read or Write access can be mapped to a COMMAND description because of a particular COMMAND description that refers to a particular VARIABLE. Such COMMAND descriptions contain communication service arguments and instructions about how to create the data payload of a communication service. If no COMMAND Description is present the VARIABLE identifier (Name) and the VARIABLE value are the only communication service Transfer arguments. Once the FDI Server has determined the communication service arguments from EDD it can map it to the communication service Transfer (FCG TS62769-7) arguments based on name matching. Transfer arguments shall have the same names, data types and semantics as described for a protocol specific COMMAND definition. Next >