< PreviousField Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 49 of 62 Example: The COMMAND description contains the attributes SLOT, INDEX, REQUEST, REPLY. The protocol specific signature of the Transfer service shall envision: Transfer( [in] String communicationRelationId, [out] Integer serviceError, [in] unsigned char SLOT, [in] unsigned char INDEX, [in] char[] REQUEST, [out] char[] REPLY) NOTE The arguments communicationRelationId and serviceError are described in FCG TS62769-7. Communication service request propagation Subclause 7.3.5 describes how the FDI Server manages the communication message propagation along the communication path. The following Figure 23 represents an example scenario derived from Figure 22. FDI Server OPC UA Information Model ServerCommunicationDeviceType : CommunicationDeviceName ConnectionPointType: CP_B_Master NetworkType: Network_B ConnectionPointType: CP_G2 ConnectionPointType: CP_B1 DeviceType: FI G101 DeviceType: FI G102 GatewayCommunicationDeviceType : Module 1 CommunicationGatewayType : Gateway_B1 ConnectionPointType: CP_G_Module NetworkType: Network_G ConnectionPointType: CP_G1 [1..n] FDI Communication Server Communication Services Hardware Driver PHY Gateway_B1 Module 1 Module 2 Module n FI G101 Network B Network G Business Logic: Module 1 METHOD Transfer(...) {... { send_command(…) } } Business Logic: FI G101 METHOD Download(...) {… { WRITE_COMMAND(...) } } Communication Processing Engine FDI Client 1 2 4 6 3 5 7 8 ServerCommunicationServiceType: CommunicationServiceProvider_B GatewayCommunicationServiceType: CommunicationServiceProvider_G Figure 23 – Message propagation example scenario NOTE 1 The numbers in brackets (1) to (8) used in the the following description refer to elements in Figure 23. The FDI Server detects a communication request because of an FDI Client (1) invoking an Action (2). The processing of that Action (METHOD Download) invokes the communication request related EDDL Built-In such as WRITE_COMMAND that has been mapped to Transfer service arguments as described in 7.3.4. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 50 of 62 The FDI Server processes the message propagation related iterations upwards through the hierarchy of the topology. The FDI Server shall always determine the next Communication Service Provider along the communication path (3) and (5) (see 7.3.2) and invoke the service Transfer there. If the Communication Service Provider processing the Transfer service is in an FDI Communication Server the Transfer service needs to be invoked using the OPC UA service Call (6). NOTE 2 The Communication Service Provider in the FDI Communication Server sends the protocol specific message to the physical network (7). If the Communication Service Provider processing the Transfer service is in a Gateway the processing of that related Business Logic will cause other communication request related EDDL Built-In invocations, for example, send_command (4). The iteration procedure enters the next recursion determining the next Communication Service Provider along the communication path (5) (see 7.3.2) and invokes the service Transfer there. NOTE 3 The gateway implementation of service Transfer is device specific. The Transfer logic wraps the incoming Transfer argument values and creates another message to be sent out calling a communication request related EDDL Built-In, see FCG TS61804-5. The Transfer logic can invoke multiple communication requests as this might be needed to manage the protocol bridge function. The physical gateway device unwraps and forwards the message (4) to the physical device (8). The FDI Server managed communication propagation process is a recursive process in which the Business Logic execution of one Device can invoke the Business Logic execution of a different Device. This FDI Server needs to maintain an invocation stack. Communication error handling The FDI Server is responsible for handling communication errors. The FDI Server detects errors either from the Communication Service Provider returned service invocation results as specified in FCG TS62769-7 or through EDDL built-ins for abort processing. The FDI Server aborts all communication Actions waiting for a response if a communication error or abort is received. The FDI Server will return a failure to the originating service if a communication error or abort is received. 7.4 FDI Communication Server specific handling Discovery FCG TS62769-7 describes the FDI Communication Server implemented discovery support in terms of: a) VARIABLE definitions describing the FDI Communication Server’s identification data that are represented in the FDI Server hosted Information Model, b) FDI Communication Server implemented usage of IEC 62541-4 specified discovery services. The FDI Server uses the services FindServers and the GetEndpoint IEC 62541-4 specified discovery service set to determine the FDI Communication Server. The FDI Server shall match the FDI Communication Server’s defined identification data with values returned from the functions FindServers and GetEndpoints. The FDI Server implements the IEC 62541-4 specified Discovery Server. Information Model synchronization According to FCG TS62769-7 the FDI Communication Package contains an EDD element describing the VARIABLES and Business Logic mapped in to the Information Model. FCG TS62769-7 also describes the overlap between the Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 51 of 62 FDI Communication Server hosted Information Model and the FDI Server hosted Information Model. This overlap represents the shared Information Model. The FDI Server synchronizes the shared Information Model: a) Any access to an offline node of the Information Model is locally handled through the Information Model. b) The FDI Server handles a write access to an online node of the Information Model by performing the same write access in FDI Communication Server hosted Information Model. c) Any read of an online node of the Information Model results in a read operation on the corresponding node of the FDI Communication Server hosted Information Model. d) Any configuration changes affecting the modular structure represented in the Information Model are copied from the FDI Server hosted Information Model to the FDI Communication Server hosted Information Model. 8 Parallel Execution within the FDI Server 8.1 Motivation Within the EDDL concept, each device is described by a set of parameters and an EDD that describes and handles relations between the parameters and their attributes. Each combination of the EDD and the respective set of parameters builds an entity describing a device instance (called EDD Entity hereafter). EDDL allows only synchronous operation with such an entity without any parallel execution. Therefore when the EDD Entity is performing an action (e.g. reading a variable value, executing a method, etc.) any other action request shall be postponed until the action execution is finished. As long as there is no relation between EDD Entities the action for EDD Entities can be executed independently and subsequent action requests can be queued without any risk to force a deadlock. As soon as relations between EDD Entities have to be handled, the FDI Server has to control the execution within the EDD Entities in a way that deadlock scenarios or parallel execution within one EDD Entity are prohibited. Nested communication is a concept based on interaction between EDD Entities. When handling multiple communications at once the FDI Server has to handle actions in the FDI system in parallel. To prevent deadlock scenarios, the FDI Server has to follow well defined execution rules. 8.2 Internal structure of the EDD interpreter A core component of an FDI Server is the EDD interpreter (see Clause A.1). The EDD interpreter can be seen as a component that consists of EDD entities. Each EDD entity itself consists of the following parts: • An associated EDD for a device or a component of a modular device. • A set of data representing the state of the EDD entity and containing data that the interpreter requires to run the EDD associated with the data set. This data for example might contain the offline data set for the associated device and cached data of the connected device. It also contains additional information the interpreter needs for EDD specific calculations. • The interpreter logic that is triggered from outside and when triggered interprets the EDD, performing subsequent activities, changes the state and delivers calculation results. 8.3 Rules for running an EDD entity As mentioned in 8.2, an activity at EDD entities is initiated always by a trigger. There are two kinds of triggers: Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 52 of 62 c) A trigger from the EDD entity itself that the interpreter logic requires for a correct EDD execution. An example for such triggers is periodic updates of dynamic variables. d) A trigger that is a consequence of a service request from outside the FDI Server. For example: 1) service requests from an FDI Client 2) service requests from an OPC-UA client The execution of an activity at an EDD entity has to follow the rules given below: a) An activity at an EDD entity is always a consequence of a trigger. b) An activity at an EDD entity cannot be interrupted. c) An activity runs until the activity is finished or aborted. d) An EDD entity can only execute one activity at a time. e) An activity executed by an EDD entity always performs a non-interruptible process from the perspective of the EDDL logic. Such processes are for example: 1) calculation of EDD objects, 2) reading a variable from a device, 3) writing a variable to a device, 4) editing a variable, 5) any activity that is embraced with pre- and post actions, 6) executing an EDD method. f) An active EDD entity may initiate sub-activities. While a sub-activity is ongoing the current activity at the EDD entity is paused. There are two kinds of sub-activities: 1) the active EDD entity calls another EDD entity (e.g. nested communication or calls using cross-block and cross-module references), 2) the active EDD entity requests another external service (e.g. communication, request for user interaction). g) While an activity is paused re-entrance for activities is possible for those activities that are a consequence of the paused activity. Activities started by other triggers have to be blocked until the paused activity at the entity is finished. h) When an activity chain of a trigger is blocked, there exists a blocking relation to another trigger and its activity chain. If this activity chain is blocked too, there is again a blocking relation to another trigger. Such series of blocking relations have to be monitored for recursion each time an activity chain has to be blocked. Recursion in the series of blocking dependencies indicates a deadlock scenario. i) The server can resolve deadlock scenarios by aborting one of the involved activity chains. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 53 of 62 Annex A (informative) FDI Server functional structure A.1 FDI functional elements The normative definition of an FDI Server is as shown in Figure 1. A non-normative view of an FDI Server shows the functional components that comprise the FDI Server and is shown in Figure A.1. FDI Server Information Model OPC UA Services Device Object Device Object Device Object EDD Communication Server Data Store System Services System Communication Hardware OPC UA Services OPC UA Services IM Management (locks, methods, etc) Communication Management HART Specific FF Specific PNO Specific EDD Interpreter (IEC 61804 Processing) EDD Builtins Figure A.1 – Functional components of an FDI Server The FDI Server functionally contains an EDD interpreter that conforms to FCG TS61804-3. The EDD interpreter provides descriptive information that is exposed in the Information Model, for example, device variables and standard menus. The EDD interpreter also provides the method execution functionality for FCG TS61804-3. Although FCG TS61804-3 defines a standard EDD language, there are protocol specific differences between EDDs. The FDI Server implements protocol specific components. The protocol specific components are used both as part of the EDD interpretation as well as for formatting communication. The FDI Server contains node management functionality that provides the support for the Information Model. The Information Management component maintains the Information Model, handles multi-user requests, including lock management, and executes methods. The functionality provided by the Information Model Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 54 of 62 management component is not restricted to FDI functionality. The IM management component may also provide general OPC UA functionality unrelated to FDI. Service requests that result in physical read and write operations are passed to a communication manager. The communication manager provides the functionality required for communication including state management of the communication requests. The communication manager contains the information to interact with system communication devices. The communication manager interacts with protocol specific components to create the actual messages transmitted on the fieldbus. The protocol specific components interact with the EDD interpreter to retrieve information from the EDD to create the protocol specific messages. The messages may be commands as in HART or the messages may be service requests as in FF. The actual message is created by the protocol specific component. The communication manager is responsible for managing the Nested Communication. The communication manager initiates the communication chain through the creation of protocol specific messages. The communication manager then passes the message through the chain of communication devices in the topology until a top level device is reached. The communication manager then interacts with the communication drivers for the top level device. The interaction may be proprietary if the communication is through a system device. The communication may also be standardized through OPC UA to an FDI Communication Server. A.2 FDI Server extension An FDI Server can be extended to support future descriptive and protocol technologies through the addition of new interpreters and protocol handlers as illustrated in Figure A.2. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 55 of 62 FDI Server Communication Server Data Store System Services System Communication Hardware OPC UA Services OPC UA Services IM Management (locks, methods, etc) Communication Management EDD HART Specific FF Specific PNO Specific EDD Interpreter (IEC 61804 Processing) EDD Builtins Future EDD Protocol specific EDD Interpreter For future EDD Builtins Figure A.2 – FDI Server extensions These extensions, just like the support for FF, HART, and PNO, are specific to the implementation provided by the vendor of the FDI Server. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 56 of 62 Annex B (informative) Access privileges and user roles B.1 User roles and usage case The specification for the Device Definition of an FDI Package contains a CLASS attribute in some elements. The CLASS attribute is supplied by the device vendor in the FDI Package and defines the intended usage of the Information Model element. The FDI Server makes the usage categories available to the system so user access and visibility to Information Model elements can be controlled by the system, possibly through the enforcement of system policies. The FDI Server reacts to the system defined policies to independently enforce the read/write access and public/private visibility of Information Model elements made available to users. Figure B.1 depicts the relationship between the FDI Package, FDI Server, FDI Client, system, and user. Legend FDI Package “Px” CLASS attribute PRIVATE attribute “other attribute” Device Description FDI Server System Policies – part of system FDI Client User Full Information ModelUser’s View of the Information Model “Access and Visibility Filter” P1 CLASS attribute PRIVATE attribute “other attribute” P2 CLASS attribute PRIVATE attribute “other attribute” Px CLASS attribute PRIVATE attribute “other attribute” Py CLASS attribute PRIVATE attribute “other attribute” P1 Px Role Based Policy User Based Policy Location Based Policy Operations Based Policy License Based Policy Denotes IM content exposed to user due to System Policy and CLASS attribute Denotes IM content exposed to user in the FDI Client due to PRIVATE attribute - Read - Write - Public - Private Read Read/Write < manages > < managed by > “other system policy” Figure B.1 – User roles and access privileges The following relationships are noted: The FDI Device Package identifies attributes associated with each element in the device description. These attributes become part of the Information Model that is managed by the FDI Server. The CLASS attribute is made available to the system through the Information Model. It is an attribute for identifying the use cases, or usage scenarios, that are applicable to the Information Model element. The FDI host can use the CLASS attribute – in particular the value SPECIALIST – to determine whether the user of the FDI Client has access to the Information Model element and what level of access is allowed. The mechanism for making this determination is part of the system policy model that is internal to the system and outside of the scope of the FDI. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3 , Ed. 1.2.0, 21 Jun 2019 Page 57 of 62 The system shall convey the access level for each Information Model element to the FDI Server so it can enforce the access model of the Information Model element for the user. The FDI Server is only the enforcer of the access rules, it does not decide “who” or “why”. The system makes all of the “who” and “why” decisions, using both the CLASS attribute provided in the FDI Package and the system policies managed by the system. Some potential system policies may include, but are not limited to the following: • Role Based Policy • User Based Policy • Location Based Policy • Operations Based Policy • License Based Policy • Other Policies B.2 Private data usage Among the attributes that have been prescribed by the FDI specification is an attribute for identifying whether an Information Model element, including data and Actions, is private to the elements in the FDI Device Package. This attribute, referred to as PRIVATE attribute in Figure B.1, determines whether an element in the Information Model is visible to FDI Clients during browse operations on the Information Model. The FDI Package elements have prior knowledge of private data and Actions in the Information Model and are able to access these private elements in accordance with access rules defined by CLASS attribute and system policy. Access and visibility are independent attributes. For example, a private Action may be limited to user access during online usage scenarios. System policy shall not be allowed to override the PRIVATE attribute in the Information Model. For example, the system policy cannot make private data public or public data private. The PRIVATE attribute is internally managed by device vendors. Field Device Integration (FDI) – Part 3: Server RELEASED FCG TS62769-3, Ed. 1.2.0, 21 Jun 2019 Page 58 of 62 Annex C (informative) Parallel execution within the FDI Server – Examples C.1 Simple example for a synchronous execution The generic examples in Clause C.1 are intended to visualize, for a better clarification, the rules given in 8.3. Figure C.1 schematically shows the simplest example of a synchronous execution of two triggered activities. Both activities can be executed independently, because different EDD entities are involved. Figure C.1 – Synchronous execution of two triggers C.2 Example for a concurrent execution Figure C.2 shows a use case where two synchronous triggers try to access one and the same activity. While the activity of trigger T1 is executed, trigger T2 is blocked. EDD Entity E1 EDD Entity E2 EDD Interpreter Trigger T1 Trigger T2 Next >