< PreviousField Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7 , Ed. 1.2.0, 27 Jun 2019 Page 19 of 59 NOTE The decision whether ValidateModules is needed or not is vendor specific. Table 2 shows the ValidateModules Action Arguments. Signature ValidateModules( [out] Int32 serviceError, [out] String ErrorMessage); Table 2 – ValidateModules 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 Action returns an empty string (NULL) the method call succeeded. In case of an error the Action can return a problem description. UIP specifics The FDI Communication Package can contain the UIP to support e.g. diagnostics and parameterization. Deployment The FDI Server imports the FDI Communication Package. The handling of EDD and UIP parts matches with the import procedure performed for the FDI Package (see FCG TS62769-2 and FCG TS62769-3). 6 Communication relations The purpose of a communication device and its communication services is to exchange information between the physical device and the device representation managed by the FDI Server. The information exchange is managed via communication relations, see Figure 3. An established communication relation represents the capability to exchange information between the FDI Server managed device representation and the physical device. The use of a Communication Relation allows abstracting from protocol specifics typically used to manage connections. Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7, Ed. 1.2.0, 27 Jun 2019 Page 20 of 59 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 3 – Communication relation NOTE 1 The core of information exchange happens between the physical network connected device and the corresponding instance within the Information Model but does not cover the complete device application. The following state chart describes the general state flow for a single communication relation. The diagram also shows which communication services can be invoked during a “CR Online” state. The “AbortIndication” shown in Figure 4 can be detected in different protocol specific ways. The one specified for any communication device is bound to the serviceErrors returned by the specified communication services. Even the Scan method can determine a connection loss, when the device for which a communication relation has been activated does not appear in a scan result. Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7 , Ed. 1.2.0, 27 Jun 2019 Page 21 of 59 CR Offline CR Online Connect() Disconnect()AbortIndication Transfer() Scan() SetAddress() Scan() Figure 4 – Communication relation state chart NOTE 2 The management of communication relations is optional. 7 FDI Communication Server definition 7.1 General In terms of FDI the FDI Communication Server is a dedicated OPC UA Server providing access to one or more field device networks. Each FDI Communication Server is modelled as a Modular Device where each module (also called CommunicationDevice in the sequence) represents the access point to one network. The Modular Device itself represents the FDI Communication Server as a whole. 7.2 General characteristics The FDI Communication Server implements characteristics for each of its CommunicationDevices specified in 7.3.3. Additionally, an FDI Communication Server implements the following characteristics: • The FDI Server always synchronizes (see 7.5, 7.8.8, and 7.8.11) the FDI Communication Server hosted Information Model from the FDI Server hosted Information Model content. • CommunicationDevices can be statically instantiated or they can be created/deleted by the FDI Server. • Communication between the FDI Server and the FDI Communication Server is based on OPC UA. OPC UA specifies a wire protocol for its services that can be implemented on arbitrary platforms and runtime environments. • To avoid race conditions, the FDI Communication Server only allows one FDI Server being connected at a time. With this restriction an FDI Communication Server can refrain from any synchronization (locking) mechanism. The FDI specification does not enforce FDI Communication Servers implementing any interlocking mechanism to manage concurrent access to a single physical network connected device. 7.3 Information Model General Subclause 7.3 specifies the FDI Communication Server hosted Information Model. Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7, Ed. 1.2.0, 27 Jun 2019 Page 22 of 59 An FDI Communication Server is an OPC UA Server that encapsulates communication hardware and provides standardized communication ability. The FDI Server connects to the FDI Communication Server as an OPC UA Client and accesses the networks supported by the FDI Communication Server via the FDI Communication Server information model. The task of the FDI Communication Server is to expose this information model. The FDI Communication Sever shall not maintain Device Instances or network topology information. All interaction with FDI devices is done through the FDI Server and just transferred by the FDI Communication Server. For the FDI Server an FDI Communication Server looks like a device that supports FDI Communication Services and uses OPC UA to communicate. The FDI Communication Server may run locally on the same PC as the FDI Server (loop back adapter) or remote in the field (e.g., embedded into a controller). Like a device each FDI Communication Server has an associated FDI Package. This FDI Package is used to create communication devices in the Information Model of the FDI Server that represent access to the networks implemented by the FDI Communication Server. The Information Model of an FDI Communication Server is based on the Information Model defined in FCG TS62769-5. Figure 5 replicates the Modular Device structure and illustrates how it maps into the overall AddressSpace. The modules represent the communication channels of the FDI Communication Server. Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7 , Ed. 1.2.0, 27 Jun 2019 Page 23 of 59 CommunicationServerType: CommunicationServer Initialize Reset AddComponent RemoveComponent ServerCommunication DeviceType: ServerCommDevice ServerCommunication ServiceType: ServiceProvider Connect Disconnect Transfer MethodSet GetPublishedData MethodSet FolderType: SubDevices ParameterSet ParameterSet ParameterSet Root Objects AddComponent RemoveComponent MethodSet SetAddress Scan ResetScan Figure 5 – FDI Communication Server AddressSpace The CommunicationServerType (the root of the Modular Device) is a subtype of the DeviceType. The MethodSet contains the methods Initialize, Reset, AddComponent and RemoveComponent. The methods AddComponent and RemoveComponent are optionally present if the FDI Communication Server supports the dynamic instantiation of elements in the folder SubDevices. All sub devices are instances of the ServerCommunicationDeviceType defined in 7.3.3. The instances of the ServerCommunicationDeviceType (ServerCommDevice) have a MethodSet that can implement the methods SetAddress, Scan, AddComponent, RemoveComponent. AddComponent and RemoveComponent are optionally present if the FDI Communication Server supports a variable number of instances of the ServerCommunicationServiceType. Formal definitions are found in 7.3.2, 7.3.3 and 7.3.4. Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7, Ed. 1.2.0, 27 Jun 2019 Page 24 of 59 CommunicationServerType 7.3.2.1 General The CommunicationServerType is a subtype of the DeviceType and provides the methods needed to manage the instances ServerCommunicationDeviceType. Figure 6 shows the CommunicationServerType definition that is formally defined in Table 3 and Table 4. CommunicationServer Type Initialize Reset AddComponent RemoveComponent MethodSet FolderType: SubDevices ParameterSet DeviceType Figure 6 – CommunicationServerType Table 3 – CommunicationServerType definition Attribute Value BrowseName CommunicationServerType IsAbstract False References NodeClass BrowseName DataType TypeDefinition ModellingRule Subtype of the DeviceType defined in IEC 62541-100. HasComponent Object MethodSet BaseObjectType Mandatory HasComponent Object ParameterSet BaseObjectType Optional HasComponent Object SubDevices FolderType Mandatory Table 4 – MethodSet of CommunicationServerType Attribute Value BrowseName MethodSet IsAbstract False References NodeClass BrowseName DataType TypeDefinition ModellingRule HasComponent Method Initialize Mandatory HasComponent Method Reset Mandatory HasComponent Method AddComponent Optional HasComponent Method RemoveComponent Optional The CommunicationServerType and each instance of this Type share the same Methods. The NodeId of these Methods will be fixed and defined in this standard. FDI Communication Server clients therefore do not have to browse for these Methods. They can use the fixed NodeId as the MethodId of the Call Service. Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7 , Ed. 1.2.0, 27 Jun 2019 Page 25 of 59 The additional Methods AddComponent and RemoveComponent add the ability to add or remove instances of ServerCommunicationDeviceType according to communication hardware structure. These services are not applicable if the FDI Communication Server implements a static communication hardware structure. The SubDevices folder contains instances of ServerCommunicationDeviceType that represent the communication modules. NOTE The indication for a static communication hardware layout is indicated in the FDI Package with COMPONENT attribute CAN_DELETE set to FALSE in COMPONENT declarations. 7.3.2.2 Reset Method Reset is used to reset the communication hardware and related driver software. Any ongoing communication will be stopped immediately. All communication channels enter the status closed. The Method Reset shall not be present in the FDI Server hosted Information Model. The FDI Server shall be able to handle the shut-down procedure automatically according to communication demands. Typically the FDI Communication Server operation includes some hardware and protocol driver handling that can be independent from any modular structure. Because of this possibility the Reset method is arranged underneath the CommunicationServerType. For the purpose of reducing the complexity of FDI Communication Server operation only one Reset method has been specified. The signature of this Method is specified below. Table 5 and Table 6 specify the arguments and AddressSpace representation, respectively. Signature Reset( [out] Int32 serviceError); Table 5 – Reset Method arguments Argument Description serviceError 0: OK -1: Failed Table 6 – Reset Method AddressSpace definition Attribute Value BrowseName Reset References NodeClass BrowseName DataType TypeDefinition ModellingRule HasProperty Variable OutputArguments Argument[] PropertyType Mandatory 7.3.2.3 Initialize Method Initialize is used to initialize the communication hardware. The initialization function of the FDI Communication Server shall use the parameterization data hosted by the ParameterSet that is contained within the instance of the CommunicationServerType and all instances of ServerCommunicationDeviceType. In order to enable parameter changes during operation the Initialize method can be re-invoked. If the FDI Communication Server needs to reset its communication hardware, it shall automatically restore any communication relation that existed. A modular FDI Communication Server can flexibly initialize only those ServerCommunicationDeviceType instances for which configuration changes have been detected. Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7, Ed. 1.2.0, 27 Jun 2019 Page 26 of 59 The Method Initialize shall not be present in the FDI Server hosted Information Model. The FDI Server shall be able to handle the start procedure automatically according to human driven communication requests. The FDI Communication Server operation can include some hardware and protocol driver handling that can be independent from any modular structure. Because of this possibility the Initialize method is arranged underneath the CommunicationServerType. For the purpose of reducing the complexity of FDI Communication Server operation only one Initialize method has been specified. The signature of this Method is specified below. Table 7 and Table 8 specify the arguments and AddressSpace representation, respectively. Signature Initialize( [out] Int32 serviceError) Table 7 – Initialize Method arguments Argument Description serviceError 0: OK -1: Failed Table 8 – Initialize Method AddressSpace definition Attribute Value BrowseName Initialize References NodeClass BrowseName DataType TypeDefinition ModellingRule HasProperty Variable OutputArguments Argument[] PropertyType Mandatory 7.3.2.4 AddComponent Method AddComponent shall be used to configure the modular setup of an FDI Communication Server in case the FDI Communication Sever has no statically defined communication hardware setup. This method shall be used to add a module (Instance of ServerCommunicationDeviceType). The signature of this Method is specified below. Table 9 and Table 10 specify the arguments and AddressSpace representation, respectively. Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7 , Ed. 1.2.0, 27 Jun 2019 Page 27 of 59 Signature AddComponent( [in] String ModuleTypeName, [in] String InstanceName, [in] String InstanceLabel, [out] NodeId InstanceNodeId, [out] Int32 ServiceError); Table 9 – AddComponent Method arguments Argument Description ModuleTypeName Type of module to be created as defined in the FDI Package. The module type name shall correspond to one of the COMPONENT identifier definitions (see 5.2.3). InstanceName Non-localized name of the module’s Device Node of the created element. This name has to be unique within the scope of the FDI Communication Server’s Information Model. InstanceLabel Human readable label for the root Node of the created module. InstanceNodeId Callee-assigned identifier for the module’s Device Node. ServiceError 0 – OK -1 – E_InvalidType – a module for the specified Type can not (not anymore) be added -2 – E_DuplicateName – there exists already a module with the same name as specified with the InstanceName argument -3 – E_UnknownType – an unknown ModuleTypeName has been specified -4 – E_LimitExceeded – the total number of modules is exceeded (this might be caused by power constraints or other resource limitations) Table 10 – AddComponent Method AddressSpace definition Attribute Value BrowseName AddComponent References NodeClass BrowseName DataType TypeDefinition ModellingRule HasProperty Variable InputArguments Argument[] PropertyType Mandatory HasProperty Variable OutputArguments Argument[] PropertyType Mandatory 7.3.2.5 RemoveComponent Method RemoveComponent shall be used to remove a module (Instance of ServerCommunicationDeviceType). Implementation of RemoveComponent is optional if the communication hardware setup is static. The signature of this Method is specified below. Table 11 and Table 12 specify the arguments and AddressSpace representation, respectively. Signature RemoveComponent( [in] NodeId ModuleNodeId, [out] Int32 ServiceError); Table 11 – RemoveComponent Method arguments Argument Description ModuleNodeId The value is the identification of the existing instance in the Information Model. ServiceError 0: OK -1: Failed, the specified node does not exist Field Device Integration (FDI) – Part 7: Communication Devices RELEASED FCG TS62769-7, Ed. 1.2.0, 27 Jun 2019 Page 28 of 59 Table 12 – RemoveComponent Method AddressSpace definition Attribute Value BrowseName RemoveComponent References NodeClass BrowseName DataType TypeDefinition ModellingRule HasProperty Variable InputArguments Argument[] PropertyType Mandatory HasProperty Variable OutputArguments Argument[] PropertyType Mandatory ServerCommunicationDeviceType 7.3.3.1 General The ServerCommunicationDeviceType represents a communication channel for a particular network. The ServerCommunicationDeviceType is a subtype of the DeviceType. The ParameterSet for each instance of a ServerCommunicationDevice will contain Parameters necessary to configure the operation of the network. Figure 7 shows the ServerCommunicationDeviceType definition that is formally defined in Table 13 and Figure 14. ServerCommunication DeviceType AddComponent RemoveComponent MethodSet SetAddress Scan ParameterSet DeviceType ServerCommunication ServiceType: ServiceProvider ResetScan Figure 7 – ServerCommunicationDeviceType Table 13 – ServerCommunicationDeviceType definition Attribute Value BrowseName ServerCommunicationDeviceType IsAbstract True References NodeClass BrowseName DataType TypeDefinition ModellingRule Subtype of the DeviceType defined in OPC UA Part DI. HasComponent Object MethodSet BaseObjectType Optional HasComponent Object ParameterSet BaseObjectType Optional HasComponent Object ServiceProvider ServerCommunication ServiceType Mandatory HasProperty Variable ListOfCommunicat ionProfiles String[] PropertyType Mandatory The Property ListOfCommunicationProfiles contains a list of communication profiles supported by the ServerCommunicationDevice. Valid strings are defined in FCG TS62769-4 – Annex F. Next >