< PreviousField Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7 , Ed. 1.2.0, 27 Jun 2019 Page 9 of 59 IEC 62541 (all parts), OPC Unified Architecture IEC TR 62541-1, OPC Unified Architecture – Part 1: Overview and Concepts IEC 62541-4, OPC Unified Architecture – Part 4: Services IEC 62541-6, OPC Unified Architecture – Part 6: Mappings IEC 62541-7, OPC Unified Architecture – Part 7: Profiles IEC 62541-100, OPC Unified Architecture – Part 100: OPC UA for Devices FCG TS62769-1, Field Device Integration (FDI) – Part 1: Overview FCG TS62769-2, Field Device Integration (FDI) – Part 2: FDI Client FCG TS62769-3, Field Device Integration (FDI) – Part 3: FDI Server FCG TS62769-4, Field Device Integration (FDI) – Part 4: FDI Packages FCG TS62769-5, Field Device Integration (FDI) – Part 5: FDI Information Model FCG TS62769-6, Field Device Integration (FDI) – Part 6: FDI Technology Mapping 3 Terms, definitions, abbreviated terms, acronyms and conventions 3.1 Terms and definitions For the purposes of this document, the terms and definitions given in FCG TS62769-1 as well as the following apply. Gateway communication device that enables to bridge between different physical networks or different protocols 3.2 Abbreviated terms and acronyms For the purposes of this document, the abbreviated terms and acronyms given in FCG TS62769-1 and the following apply. HTTP Hypertext Transfer Protocol IP PHY Internet Protocol Physical communication hardware SNMP Simple Network Management Protocol TCP Transmission Control Protocol URI Uniform Resource Identifier 3.3 Conventions for graphical notation This document uses the graphical notation defined in FCG TS62769-5. Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7, Ed. 1.2.0, 27 Jun 2019 Page 10 of 59 4 General The abstract term FDI Communication Device represents an entity implementing communication functions over a network using a specific protocol. The group of FDI Communication Devices splits into two main groups. a) The FDI Communication Server is a dedicated OPC UA Server providing access to one or more field device networks. The FDI Communication Server is specified in Clause 7. b) The FDI Communication Gateway enables to bridge between different physical networks or different protocols. The bridging business logic is implemented in the EDD component that is provided with an FDI Communication Package. The FDI Communication Gateway is specified in Clause 8. NOTE The main differences between a Gateway and a Communication Server are: in terms of FDI the FDI Communication Server is a dedicated OPC UA Server providing access to one or more field device networks. A Gateway is a communication device that enables to bridge between different physical networks or different protocols. The logical representation of a Gateway device within the FDI Server hosted Information Model enables the FDI Server to process communication in heterogeneous network topologies. 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 Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7 , Ed. 1.2.0, 27 Jun 2019 Page 11 of 59 Figure 2 – FDI communication infrastructure architecture The FDI Server hosted Information Model contains a representation of the network topology. (see also FCG TS62769-5). The Information Model shown in Figure 2 is an example excerpt to illustrate how the Information Model used elements reflect the actual network topology. 1) The instance of CommunicationServerType (named CommunicationServerName) represents the FDI Communication Server. The FDI Communication Server implements physical communication network access (Communication hardware). Clause 7 describes related Information Model specifics, required FDI Communication Package content and handling of elements therein. (For subdevices see FCG TS62769-5) 2) The instance of ServerCommunicationDeviceType and ServerCommunication-ServiceType (named Network_B_Channel) maps to the FDI Communication Server implemented communication services. The ServerCommunicationDeviceType is specified in 7.3.3. The ServerCommunicationServiceType is specified in 7.3.4. 3) The instance of CommunicationGatewayType (named Gateway_B1) represents the physical Gateway. Clause 8 describes the related Information Model specifics, the required FDI Package content and the handling of elements therein. 4) The instance of GatewayCommunicationDeviceType (named Module 1) maps to a physical or logical module enabling communication to the network to which this module is connected. The GatewayCommunicationDeviceType is specified in 8.3.2.3. The related Gateway specifics are described in Clause 8. 5) The instance of GatewayCommunicationServiceType (named CommunicationServiceProvider_G) represents the Gateways’ ability to process communication services. The Gateway specific implementation of GatewayCommunicationServiceType is based on Business Logic that enables to run communication services in heterogeneous communication networks. 6) A communication relation (more details are described in Clause 6) between a physical device and the device representation managed by the FDI Server is always associated to communication service objects that are instances of a GatewayCommunicationServiceType or ServerCommunicationServiceType. The ability of instantiating multiple communication service objects supports protocols enables to operate multiple logical connections between a bus master and a device. 7) The Information Model represents the connections between the physical devices shown on the left side of Figure 2 based on instances of ConnectionPointType NetworkType and the depicted relations. ConnectionPointType and NetworkType are specified in FCG TS62769-5. 5 FDI Communication Package 5.1 General The FDI Server imports the FDI Communication Package like any other FDI Device Package. Clause 5 specifies the FDI Communication Package details. 5.2 EDD General rules The FDI Communication Package contained EDD is not restricted, but bound to a protocol specific profile (see FCG TS62769-4 – Annex F). The EDD elements as specified in the protocol specific profile documents (see FCG TS62769-4 – Annex F), and provided with an FDI Communication Package shall describe: Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7, Ed. 1.2.0, 27 Jun 2019 Page 12 of 59 a) Parameter and parameter structures. Mandatory protocol specific parameter definitions are found in the protocol specific profile documents (see FCG TS62769-4:–, Annex F). The parameters shall contain any parameter that requires adjustment for proper communication service operation. b) Physical Layer identification. Protocol specific definitions are found in FCG TS62769-4:–, Annex F. c) Communication devices modularity: The modularity information shall be based on using the EDDL constructs COMPONENT (see FCG TS61804-3). FDI envisions communication device modularity to cope with communication hardware providing multiple physical or logical communication channels to access multiple logical or physical communication networks. Each module element of the whole communication device shall be described by a separate EDD element. d) The COMPONENT definition shall be used to support the system implemented topology configuration. Protocol specific definitions are found in the protocol specific profile documents (see FCG TS62769-4 – Annex F). The related COMPONENT definitions are described in 5.2.2, 5.2.3, 5.2.4, and 5.2.7. e) The Business Logic shall contain a method enabled to validate the network (see 5.2.8). The validation function considers the elements only directly connected to the network. The validation function shall be referred by the EDDL specified CHECK_CONFIGURATION attribute. f) The Business Logic can contain a method enabled to validate the module configuration (see 5.2.9) or the network configuration (see 5.2.8). The validation function considers the elements only directly connected to the related parent element in the topology. The validation function shall be referred by the EDDL specified CHECK_CONFIGURATION attribute. g) Connection Point data: The Connection Point (see 5.2.4 and 5.2.6) shall be described through EDDL constructs COMPONENT, COLLECTION and VARIABLE. The COMPONENT definition associates the Connection Point element to the Communication Device. The VARIABLE definitions represent the properties of a specific Connection Point. The COLLECTION represents the Connection Point structure as such. Protocol specific definitions are found in FCG TS62769-4 – Annex F. h) MENU: The Menu structure shall follow the Menu conventions for PC based applications according to FCG TS61804-4 enabling access to 1) FDI Communication Device Type (Bus) parameters: These parameters shall be made accessible by means of “offline_root_menu”. 2) Topology Configuration Dialogs shall be made available by means of the menu entry point “topology_configuration”. Device component Each FDI Communication Package shall contain an EDD element describing the device. COMPONENT <DeviceComponentId> { LABEL "<Label>"; CAN_DELETE TRUE; CHECK_CONFIGURATION <ValidateModules>; CLASSIFICATION NETWORK_COMPONENT; COMPONENT_RELATIONS { <CommunicationDeviceRelationId> } } COMPONENT_RELATION <CommunicationDeviceRelationId> { LABEL "Relation type description"; RELATION_TYPE CHILD_COMPONENT; Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7 , Ed. 1.2.0, 27 Jun 2019 Page 13 of 59 ADDRESSING {<AddressVar>} COMPONENTS { <CommunicationDeviceComponentId> { AUTO_CREATE <autoCreate>; REQUIRED_RANGES { <AddressVar>{ MIN_VALUE <AddrMin>; MAX_VALUE <AddrMax>;} } } } MINIMUM_NUMBER <minNumber>; MAXIMUM_NUMBER <maxNumber>; } <DeviceComponentId> : The COMPONENT identifier identifies the component description for the device type. <Label> : The string value shall contain a string that allows a human user to determine the function of the FDI Communication Server object. <ValidateModules> : The Value refers to the METHOD implementing the module topology configuration validation function. (Implementation details are specified in 5.2.9.) The attribute COMPONENT_RELATIONS allows to describe how modules can be connected. The definition of the COMPONENT_RELATIONS is optional. If used it shall describe the relations to the CommunicationDevice definitions. The construct enables to perform generic, FDI Server driven (device) topology configuration. Syntax details are described in FCG TS61804-3. The subsequent text describes the semantic use of the COMPONENT_RELATION construct. <CommunicationDeviceRelationId> : The attribute value identifies the COMPONENT_RELATION definition describing the relation between the device component and the CommunicationDevice component. <CommunicationDeviceComponentId> : The attribute value has to match with a COMPONENT identifier used in a COMPONENT declaration that describes a CommunicationDevice (see 5.2.3). <autoCreate> : The attribute value describes the number of CommunicationDevice components that can be automatically instantiated with the Device component. <minNumber> / <maxNumber> / <autoCreate> : The attribute values define the instantiation constraints. The definition of these attributes is optional. The attribute values can contain conditional expressions. The RELATION_TYPE shall be set to CHILD_COMPONENT . <AddressVar> : The attribute value is a reference to a VARIABLE declaration. This VARIABLE holds the address value for a CommunicationDevice instance. The definition of this attribute is optional. <AddrMin>/<AddrMax> : Values define the address value range for a CommunicationDevice instance. The value may for example correspond to a physical slot number. Usage of attributes ADDRESSING and REQUIRED_RANGES enables generic configuration routines. CommunicationDevice component Each FDI Communication Package shall contain at least one EDD element describing at least one CommunicationDevice component. A modular communication hardware structure shall be described by multiple CommunicationDevice COMPONENT descriptions: Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7, Ed. 1.2.0, 27 Jun 2019 Page 14 of 59 COMPONENT <CommunicationDeviceComponentId> { LABEL "<Label>"; CAN_DELETE <CanDelete>; CLASSIFICATION NETWORK_COMPONENT; COMPONENT_RELATIONS { <CommunicationServiceProviderRelationId> } } COMPONENT_RELATION <CommunicationServiceProviderRelationId> { LABEL "Relation between CommunicationDevice and communication service provider"; RELATION_TYPE CHILD_COMPONENT; ADDRESSING {<AddressVar>} COMPONENTS { <CommunicationServiceProviderId> { AUTO_CREATE <autoCreate>; } } MINIMUM_NUMBER 1; MAXIMUM_NUMBER <maxNumber>; } < CommunicationDeviceComponentId >: The COMPONENT identifier identifies the CommunicationDevice component. <Label> : The string value shall contain a human readable string that allows a user to easily determine the function of the CommunicationDevice component. <CanDelete> : Allowed values are TRUE or FALSE. It depends on whether a CommunicationDevice needs explicit configuration or whether the related communication service provider object shall be automatically instantiated with the CommunicationDevice. If the attribute CAN_DELETE is set to FALSE the CommunicationDevice configuration is static. The definition of the COMPONENT_RELATIONS is mandatory. It describes the relation to the communication service provider definition. The construct enables the FDI Server to instantiate communication service provider components according to communication processing demands. (Syntax details are described in FCG TS61804-3.) The subsequent text describes the semantic use of the COMPONENT_RELATION construct. <CommunicationServiceProviderRelationId> The attribute value identifies the COMPONENT_RELATION definition as such. <CommunicationServiceProviderId> : The attribute value has to match with a COMPONENT identifier used in a COMPONENT declaration that describes a communication service provider (5.2.4). <autoCreate> : The attribute value describes the number of communication service providers that can be automatically instantiated with the CommunicationDevice component. The RELATION_TYPE shall be set to CHILD_COMPONENT . The PROTOCOL attribute shall not be set. Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7 , Ed. 1.2.0, 27 Jun 2019 Page 15 of 59 Communication service provider component Each FDI Communication Package describing a Communication Device shall contain at least one EDD element describing the communication service provider. The EDD component shall not define any configuration parameter. COMPONENT <CommunicationServiceProviderId> { LABEL "<Label>"; BYTE_ORDER <byteOrder>; CAN_DELETE <CanDelete>; CLASSIFICATION NETWORK_COMMUNICATION_SERVICE_PROVIDER; COMPONENT_RELATIONS <CommunicationServiceProvidersConnectionPointRelationId> { <ConnectionPointRelationId> } } COMPONENT_RELATION <CommunicationServiceProvidersConnectionPointRelationId> { LABEL "Relation between communication service provider and connection point"; RELATION_TYPE CHILD_COMPONENT; ADDRESSING {<AddressVar>} COMPONENTS { < ConnectionPointId> { AUTO_CREATE 1; } } MINIMUM_NUMBER 1; MAXIMUM_NUMBER 1; } < CommunicationServiceProviderId >: The COMPONENT identifier identifies the communication service provider. <Label> : The string value shall contain a human readable string that allows a user to easily determine the function of the communication service provider object. <CanDelete> : Allowed values are TRUE or FALSE. It depends on whether a communication service provider can be flexibly instantiated according to the communication processing demands. If the attribute CAN_DELETE is set to FALSE the number of communication service provider component instantiations is static. The instantiation constraints declared through the attributes AUTO_CREATE, MINIMUM_NUMBER and MAXIMUM_NUMBER correspond to the capabilities of currently supported protocols. <byteOrder> : The value enables generic integration of n-byte data types (e.g. 4-byte Integer) into the communication message payload. The attribute value describes the byte order and shall be either BIG_ENDIAN or LITTLE_ENDIAN. The definition of the COMPONENT_RELATIONS is mandatory. It describes the relation to the Connection Point definition. The construct enables to perform generic, FDI Server driven topology configuration. (Syntax details are described in FCG TS61804-3.) The subsequent text describes the semantic use of the COMPONENT_RELATION construct. The Connection Point shall automatically be instantiated with the communication service provider and there shall be exactly one (1) Connection Point instance connected to the communication service provider. The Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7, Ed. 1.2.0, 27 Jun 2019 Page 16 of 59 instantiation constraints declared through the attributes AUTO_CREATE, MINIMUM_NUMBER and MAXIMUM_NUMBER correspond to the capabilities of currently supported protocols. <CommunicationServiceProvidersConnectionPointRelationId> The attribute value identifies the COMPONENT_RELATION declaration as such. <ConnectionPointId> : The attribute value has to match with a COMPONENT identifier used for a COMPONENT declaration that describes a Connection Point (see 5.2.5). The RELATION_TYPE shall be set to CHILD_COMPONENT . The PROTOCOL attribute shall not be set. Connection Point component Each FDI Communication Package describing a Communication Device shall contain one EDD element describing one Connection Point for each of the protocols that are supported by the Communication Device: COMPONENT <ConnectionPointId> { LABEL "<Label>"; CAN_DELETE FALSE; CLASSIFICATION NETWORK_CONNECTION_POINT; PROTOCOL <ProtocolId>; CONNECTION_POINT <ConnectionPointCollectionId>; } < ConnectionPointId >: The COMPONENT identifier identifies the Connection Point component declaration. <Label> : The string value shall contain a string that allows a human user to determine the function of the Connection Point component. <ProtocolID> : The value of this attribute indicates the communication capability which allows the FDI Server to find other device types that can be connected to the network using the same type of protocol. For standardized protocols the value is defined by the related field bus organization. <ConnectionPointCollectionId> : The attribute value is a reference to a COLLECTION declaration that describes the data structure of the Connection Point as described in 5.2.6 . Connection Point collection Each EDD describing the Connection Point of a communication device shall describe the COLLECTION element that describes the attributes that shall appear in the Information Model representation of the Connection Point. The protocol specific data exposed by the Connection Point identifies the device type and its network address. COLLECTION <ConnectionPointCollectionId> { LABEL "<Label>"; MEMBERS { <AddressAttributeName>, <AddressAttributeVariableId>; VALID <VALID_VariableId>; } } <ConnectionPointCollectionId> : The identifier of the COLLECTION is referred by the CONNECTION_POINT attribute value defined in 7.7.3.5. <Label> : The label identifies the Connection Point in a human readable way. Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7 , Ed. 1.2.0, 27 Jun 2019 Page 17 of 59 <AddressAttributeName>/<AddressAttributeVariableId> : The MEMBER section refers to the VARIABLE definitions describing the address attributes implemented by a Connection Point. The content of the MEMBER section is protocol specific. <VALID>/<VALID_VariableId> is a Collection member referring a Boolean VARIABLE holding the validation status that shall be set by the ValidateNetwork Action (see 5.2.8). Network component Each FDI Communication Package describing a Communication Device shall contain one EDD element describing one Network for each of the protocols that are supported by the Communication Device. The definition supports the network topology engineering: COMPONENT <NetworkComponentId> { LABEL "<Label>"; CAN_DELETE TRUE; CHECK_CONFIGURATION <Validate>; CLASSIFICATION NETWORK; PROTOCOL <ProtocolId>; COMPONENT_RELATIONS { <NetworksConnectionPointRelationId> } } COMPONENT_RELATION <NetworksConnectionPointRelationId> { LABEL "Relation between network and connection point"; RELATION_TYPE CHILD_COMPONENT; ADDRESSING {<AddressVar>} COMPONENTS { <ConnectionPointId> { REQUIRED_RANGES { <BusAddressVar>{ MIN_VALUE <BusAddrMin>; MAX_VALUE <BusAddrMax>;} } } } MINIMUM_NUMBER 1; MAXIMUM_NUMBER <maxNumber>; } <NetworkComponentId> : The COMPONENT identifier identifies the Network component declaration. <Label> : The string value shall contain a human readable string that allows a user to easily determine the function of the Network component. <Validate> : The Value refers to the METHOD implementing the network topology configuration validation function (see 5.2.8). <ProtocolID> : The value of this attribute allows the FDI Server to find other device types that can be connected to the network using the same type of protocol. For standardized protocols the value is defined by the related fieldbus organization. The definition of the COMPONENT_RELATIONS is mandatory. It describes the relation to the Connection Point definition and by that the capabilities of a network. The construct enables to perform generic, FDI Server driven Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7, Ed. 1.2.0, 27 Jun 2019 Page 18 of 59 network topology configuration. Syntax details are described in FCG TS61804-3. The subsequent text describes the semantic use of the COMPONENT_RELATION construct. <NetworksConnectionPointRelationId> The attribute value identifies the COMPONENT_RELATION definition. <ConnectionPointId> : The attribute value has to match with a COMPONENT identifier used for a COMPONENT declaration that describes a Connection Point (see 5.2.4). <maxNumber : The attribute value limits the number of Connection Points that can be connected to the network. The attribute values can contain conditional expressions. The RELATION_TYPE shall be set to CHILD_COMPONENT . <BusAddressVar> : The attribute value is a reference to a VARIABLE declaration. This VARIABLE holds the network address value for any device that is connected to the network. <BusAddrMin>/<BusAddrMax> : Values define the network address value range. ValidateNetwork The method ValidateNetwork represents the Communication Device implemented Business Logic that validates a current network topology. The ValidateNetwork method handles any necessary dependencies related to bus parameters. The implementation of related EDDL logic is based on the EDDL Built-in function ObjectReference, which enables to analyze a set of child instances (Connection Point instances). The validation logic shall set the <VALID> attribute of the Connection Point instance that has passed the validation. The implementation of ValidateModules is optional if the module setup is either static or if the configuration rules defined in the COMPONENT construct are sufficient to configure the module setup. Table 1 shows the ValidateNetwork Action Arguments. Signature ValidateNetwork( [out] Int32 ServiceError, [out] String ErrorMessage); Table 1 – ValidateNetwork Action arguments Argument Description ServiceError 0: OK -1: Failed / the Connection Point that did not pass the validation is indicated by the <VALID> attribute () value set to false. Remark: The argument values correspond to the FCG TS61804-3 specified error codes named BI_SUCCESS (value = 0) and BI_ERROR (value = -1). The Action returns the ServiceError result using the “return” statement. ErrorMessage If the method returns an empty string (NULL) the Action call succeeded. In case of an error the Action can return a problem description. ValidateModules The method ValidateModules validates the current module setup. The implementation of the related EDDL logic is based on the EDDL Built-in function ObjectReference, which enables to analyze a set of child instances. The implementation of ValidateModules is optional if the module setup is either static or if the configuration rules defined in the COMPONENT construct are sufficient to configure the module setup. Next >