< PreviousField Device Integration (FDI) – Part 101-1: Profiles – Foundation Fieldbus H1 RELEASED FCG TS62769-101-1 , Ed. 1.2.0, 09 Jul 2019 Page 19 of 31 Argument Description -11: Transfer Failed / data value is never writeable a -12: Transfer Failed / duplicate BlockTag detected -13: Invalid INDEX, SUB_INDEX argument provided with a “VIEW_READ” transfer The FDI Server maintains an Information Model defined in IEC 62541-100. Hence topology elements representing an FFBlockType are separated from actual block instances. An instance called Blocks of a ConfigurableObjectType is used to implement instantiation rules. Instantiation of blocks is further detailed with IEC 62769-5. According to the rules defined in IEC 62769-5, the FDI Server needs to gather information of the FF Directory object in order to be able to create block instances. This information shall be provided by the Scan Method defined in 5.6.1.7. According to IEC 62769-5, the BlockTag argument denoted above is obtained from the DisplayName attribute of the corresponding Block instance within the FDI Information Model. NOTE 1 IEC 62769-7, defines the argument SendData of the Transfer Method as an array of Variant. The arguments OPERATION, BlockTag, INDEX, SUB_INDEX and WriteData defined in the table are represented as entries of the Variant array in the order they are specified above. NOTE 2 IEC 62769-7, defines the argument ReceiveData of the Transfer Method as an array of Variant. The argument ReadData defined in the table is represented as an entry of the Variant array in the order specified above. NOTE 3 Example (for clarification): A block has two views of type View_4. The first view of type View_4 is addressed with the arguments INDEX = 4 and SUB_INDEX = 1. The second view is addressed with the arguments INDEX = 4 and SUB_INDEX = 2. a A ServiceError value may be returned with a write operation. GetPublishedData CP 1/1 alerts represent unsolicited messages as defined in IEC 62769-7. Table 13 shows the Method GetPublishedData arguments. NOTE CP 1/1 uses the term alerts to refer to alarms and event messages. These are asynchronous, unsolicited messages that deliver state change notifications such as diagnostic conditions. These messages are mapped to the GetPublishedData service. CP 1/1 also uses the term publish to refer to synchronous, network scheduled communication for process values. These published messages are not mapped to the GetPublishedData service. Signature: GetPublishedData( [in] ByteString CommunicationRelationId, [out] String BlockTag, [out] Byte[] AlarmEventData, [out] NodeId AlarmEventType, [out] DateTime TimeStamp, [out] Int32 ServiceError); Table 13 – Method GetPublishedData arguments Argument Description CommunicationRelationId The argument value contains the nodeId of the ConnectionPoint representing the connection between a device and a physical network within the Information Model. BlockTag The output argument denotes the Block tag of the block instance that issued the alarm or event. AlarmEventData With this argument the alarm/event data byte stream is returned as a byte array. Field Device Integration (FDI) – Part 101-1: Profiles – Foundation Fieldbus H1 RELEASED FCG TS62769-101-1, Ed. 1.2.0, 09 Jul 2019 Page 20 of 31 Encoding of integers shall follow the rules defined in IEC 62541-6. AlarmEventType NodeId of the alarm or event type node defined within the FDI Information model to decode the alarm / event data stream. The alarm and event types shall be read from the EDD by the FDI Server when creating the Information Model. TimeStamp Denotes the time the alarm or event was detected by the device. ServiceError 0: OK / execution finished. -1: GetPublishedData Failed / canceled by caller -2: Call Failed / unknown service ID -3: GetPublishedData Failed / not supported -4: GetPublishedData Failed / no existing communication relation. -5: GetPublishedData Failed / invalid communication relation identifier -8: GetPublishedData Failed / no alarm/avent data published. -9: GetPublishedData Failed / invalid AlarmEventType The FDI Server maintains an Information Model defined in IEC 62541-100. Hence topology elements representing an FFBlockType are separated from actual block instances. An instance called Blocks of a ConfigurableObjectType is used to implement instantiation rules. Instantiation of blocks is further detailed with IEC 62769-5. According to the rules defined in IEC 62769-5, the FDI Server needs to gather information of the FF Directory object in order to be able to create block instances. This information shall be provided by the Scan Method defined in 5.6.1.7. According to IEC 62769-5, the BlockTag argument denoted above is obtained from the DisplayName attribute of the corresponding Block instance within the FDI Information Model. A ServiceError value may be returned with a write operation. NOTE 1 IEC 62769-7, defines the argument ReceiveData of the GetPublishedData Method as an array of Variant. The arguments BlockTag, AlarmEventData and AlarmEventType defined in the table are represented as entries of the Variant array in the order they are specified above. NOTE 2 IEC 62769-7, defines the argument SendData of the Transfer Method as an array of Variant. The arguments OPERATION, BlockTag, INDEX, SUB_INDEX and WriteData defined in the table are represented as entries of the Variant array in the order they are specified above. NOTE 3 IEC 62769-7, defines the argument ReceiveData of the Transfer Method as an array of Variant. The argument ReadData defined in the table is represented as an entry of the Variant array in the order specified above. SetAddress Table 14 shows the Method SetAddress arguments. NOTE: Modifying the address of a device will have an impact on the communications of a distributed control system (DCS) if present. Setting the address of a device will take a significant amount of time. Field Device Integration (FDI) – Part 101-1: Profiles – Foundation Fieldbus H1 RELEASED FCG TS62769-101-1 , Ed. 1.2.0, 09 Jul 2019 Page 21 of 31 Signature SetAddress( [in] String OPERATION, [in] UInt16 LinkId, [in] byte OldAddress, [in] byte NewAddress, [in] String NewPDTag [in] UInt32 ServiceId, [out] Int32 ServiceError); Table 14 – Method SetAddress arguments Argument Description OPERATION a The argument value indicates the type of addressing operation. The allowed values are “SETASSIGNMENT”, “CLEARASSIGNMENT”. Argument values given with the arguments below may be ignored depending on the value of the OPERATION argument. LinkId a The argument name shall match with the corresponding BrowseName of the Variable defined as a component of an instance of type ServerCommunicationDeviceType (refer to 5.5.2). The argument value is passed by the parent instance of a ServerCommunicationDeviceType. The value may be obtained by the Scan Method or may be directly configured. OldAddress a The argument value holds the current address of a device. Allowed values are 16...255. NewAddress b The argument value holds the new address for a device. Allowed values are 0 and 16...247. The value is 0 if the service is not being used to change the H1 device’s address. The argument value is ignored if the OPERATION argument value is “CLEARASSIGNMENT”. NewPDTag b The argument value holds the new PD-Tag to set for the device. The argument value is ignored if the OPERATION argument value is “CLEARASSIGNMENT”. ServiceId The service transaction code establishes the relation between the service request and the corresponding response ServiceError 0: OK / execution finished successfully -1: SetAddress Failed / canceled by caller -2: Call Failed / unknown service ID -3: SetAddress Failed / not initialized -4: SetAddress Failed / not connected to a network -5: SetAddress Failed / no device found responding to oldAddress -6: SetAddress Failed / duplicate address error -7: SetAddress Failed / device did not accept new address -8: SetAddress Failed / invalid oldAddress (in terms of syntax, data type, data format, and so on) -9: SetAddress Failed / invalid newAddress (in terms of syntax, data type, data format, and so on) -10: SetAddress Failed / not possible in status connected a IEC 62769-7 defines the argument OldAddress of the SetAddress Method as an array of Variant. The arguments OPERATION, OldAddress and LinkId defined in the table are represented as entries of the Variant array in the order they are specified above. b IEC 62769-7 defines the argument NewAddress of the SetAddress Method as an array of Variant. The arguments NewAddress and NewPDTag defined in the table are represented as entries of the Variant array in the order they are specified above. Field Device Integration (FDI) – Part 101-1: Profiles – Foundation Fieldbus H1 RELEASED FCG TS62769-101-1, Ed. 1.2.0, 09 Jul 2019 Page 22 of 31 Scan The Method signature specified in IEC 62769-7 applies. The corresponding topologyScanResult schema is specified in Annex A. ResetScan The Method signature specified in IEC 62769-7 applies. Methods for Gateways Not supported in this standard. Field Device Integration (FDI) – Part 101-1: Profiles – Foundation Fieldbus H1 RELEASED FCG TS62769-101-1 , Ed. 1.2.0, 09 Jul 2019 Page 23 of 31 Annex A (normative) Topology scan schema A.1 General The topology scan result schema specified in Annex A describes the CP 1/1 specific format Method Scan argument topologyScanResult . The XML document content and structure shall correspond to the Information Model designed concept to describe a topology in order to enable generic matching between physical devices connected to the network and the FDI Server hosted Information Model. A.2 FoundationH1AddressT A simple type that defines the address structure for CP 1/1. The XML schema for a FoundationH1AddressT type is: <xsd:simpleType name="FoundationH1AddressT"> <xsd:restriction base="xsd:unsignedByte"> <xsd:minInclusive value="16"/> <xsd:maxInclusive value="255"/> </xsd:restriction> </xsd:simpleType> A.3 FoundationH1ConnectionPointT A complex type that defines the Connection Point for CP 1/1. The XML schema for a FoundationH1ConnectionPointT type is: <xsd:complexType name="FoundationH1ConnectionPointT"> <xsd:sequence> <xsd:element name="Identification" type="ff:FoundationIdentificationT"/> <xsd:element name="BlockScanInstance" type="ff:FoundationBlockIdentificationT" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="Address" type="ff:FoundationH1AddressT" use="required"/> <xsd:attribute name="SIFConnection" type="xsd:boolean" use="required"/> <xsd:attribute name="OrdinalNumber" type="xsd:unsignedInt" use="required"/> </xsd:complexType> The attributes of a FoundationH1ConnectionPointT type are described in Table A.1. Table A.1 – Attributes of FoundationH1ConnectionPointT Attribute Description Address The Attribute value holds the address of the network connected device. SIFConnection SIFConnection denotes whether a SIF Connection is necessary or not OrdinalNumber The OrdinalNumber property reflects the position of the VFD within the System Management VFD list. Multiple VFDs are mapped to multiple ScanItem Field Device Integration (FDI) – Part 101-1: Profiles – Foundation Fieldbus H1 RELEASED FCG TS62769-101-1, Ed. 1.2.0, 09 Jul 2019 Page 24 of 31 elements. The elements of a FoundationH1ConnectionPointT type are described in Table A.2. Table A.2 – Elements of FoundationH1ConnectionPointT Element Description Identification The element data holds the device type identification data. Compared to the Information Model (IEC 62769-5) the ConnectionPoint does not contain or refer to the device type identification data. But in order to support the FDI host system in finding the package that matches the connected device this schema associates the device type identification with the ConnectionPoint. BlockScanInstance Block instance information of the scanned device VFD. Used to create Block instances within FDI Server IM. See IEC 62769-5. A.4 FoundationH1NetworkT A complex type that defines the network for CP 1/1. The XML schema for a FoundationH1NetworkT type is: <xsd:complexType name="FoundationH1NetworkT"> <xsd:sequence> <xsd:element name="ConnectionPoint" type="ff:FoundationH1ConnectionPointT" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> The elements of a FoundationH1NetworkT type are described in Table A.3. Table A.3 – Elements of FoundationH1NetworkT Element Description ConnectionPoint CP 1/1 Connection Point. A.5 Network The root element that is used to return the scan result of a CP 1/1 network. The XML schema for a Network element is: <xsd:element name="Network" type="ff:FoundationH1NetworkT"/> A.6 FoundationBlockIdentificationT A complex type that defines the block instance information of the scanned device. The XML schema for a FoundationBlockIdentificationT type is: <xsd:complexType name="FoundationBlockIdentificationT"> <xsd:attribute name="BlockTag" use="required"/> <xsd:attribute name="DDItem" use="required"/> Field Device Integration (FDI) – Part 101-1: Profiles – Foundation Fieldbus H1 RELEASED FCG TS62769-101-1 , Ed. 1.2.0, 09 Jul 2019 Page 25 of 31 <xsd:attribute name="DirectoryPosition" use="required"/> </xsd:complexType> The attributes of a FoundationBlockIdentificationT type are described in Table A.4. Table A.4 – Attributes of FoundationBlockIdentificationT Attribute Description BlockTag The BlockTag attribute shall be mapped to the DisplayName of a block instance to be created within the FDI Server IM. DDItem This attribute is used to find the correct block type of a block instance to be created within the FDI Server IM. The block type is looked up within the SupportedTypes Folder in the Blocks component of a DeviceType. DirectoryPosition This attribute denotes the relative position of the block instance within the Directory object. The first block instance has a value of 0. See block instantiation rules in IEC 62769-5. A.7 FoundationIdentificationT A complex type that defines the content corresponds to the FunctionalGroup Identification. The XML schema for a FoundationIdentificationT type is: <xsd:complexType name="FoundationIdentificationT"> <xsd:attribute name="MANUFAC_ID" type="xsd:unsignedInt" use="required"/> <xsd:attribute name="DEV_TYPE" type="xsd:unsignedShort" use="required"/> <xsd:attribute name="DEV_REV" type="xsd:unsignedShort" use="optional"/> <xsd:attribute name="ITK_VER" type="xsd:unsignedShort" use="optional"/> <xsd:attribute name="HARDWARE_REV" type="xsd:string" use="optional"/> <xsd:attribute name="SOFTWARE_REV" type="xsd:string" use="optional"/> <xsd:attribute name="COMPATIBILITY_REV" type="xsd:unsignedInt" use="optional"/> <xsd:attribute name="CAPABILITY_LEV" type="xsd:unsignedByte" use="optional"/> <xsd:attribute name="SIF_ITK_VER" type="xsd:unsignedShort" use="optional"/> <xsd:attribute name="FD_VER" type="xsd:unsignedShort" use="optional"/> </xsd:complexType> The attributes of a FoundationIdentificationT type are described in Table A.5. Table A.5 – Attributes of FoundationIdentificationT Attribute Description MANUFAC_ID Manufacturer identification number. DEV_TYPE Manufacturer model number associated with the resource. DEV_REV Manufacturer revision number associated with the resource. Conditional: Shall be available if the device exposes a Function block VFD. ITK_VER ITK Profile Number. Conditional: Shall be available if the device exposes a Function block VFD. HARDWARE_REV Manufacturer hardware revision. SOFTWARE_REV Manufacturer software revision. Field Device Integration (FDI) – Part 101-1: Profiles – Foundation Fieldbus H1 RELEASED FCG TS62769-101-1, Ed. 1.2.0, 09 Jul 2019 Page 26 of 31 Attribute Description COMPATIBILITY_REV This parameter is optionally used when replacing field devices. The correct usage of this parameter presumes the COMPATIBILITY_REV value of the replacing device should be equal to or lower than the DEV_REV value of the replaced device. CAPABILITY_LEV This parameter may be included in a device to indicate the capability level supported by a device. SIF_ITK_VER SIF ITK Profile Number FD_VER A parameter equal to the value of the major version of the Field Diagnostics specification that this device was designed for. Field Device Integration (FDI) – Part 101-1: Profiles – Foundation Fieldbus H1 RELEASED FCG TS62769-101-1 , Ed. 1.2.0, 09 Jul 2019 Page 27 of 31 Annex B (normative) Transfer service parameters B.1 General Direct Access Services specified in IEC 62769-2 enable the User Interface Plug-in (UIP) to directly exchange data with the device. Direct data exchange means that data exchanged between a device and a UIP may not be reflected in the Information Model. The IEC 62769-6 defined interface IDirectAccess corresponds to the IEC 62769-2 specified Direct Access Services. Interface IDirectAccess defined functions BeginTransfer and EndTransfer need to convey protocol specific information. The protocol specifics shall be captured in an XML document. B.2 receiveData An element contains data that is returned through IDirectAccess function Transfer defined argument receiveData. The XML schema for a receiveData element is: <xsd:element name="receiveData"> <xsd:complexType> <xsd:complexContent> <xsd:extension base="ff:TransferResultDataT"> <xsd:sequence> <xsd:element name="ResponseCode" type="ff:ResponseCodeT" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> The elements of a receiveData element are described in Table 1. Table 1 – Elements of receiveData Element Description ResponseCode Optional element that holds the return values for a negative service response. B.3 sendData An element contains data that is submitted through the IDirectAccess function Transfer defined argument sendData. The XML schema for a sendData element is: <xsd:element name="sendData" type="ff:TransferSendDataT"/> Field Device Integration (FDI) – Part 101-1: Profiles – Foundation Fieldbus H1 RELEASED FCG TS62769-101-1, Ed. 1.2.0, 09 Jul 2019 Page 28 of 31 B.4 OperationT A simple type that defines service operations. The XML schema for an OperationT enumeration type is: <xsd:simpleType name="OperationT"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="READ"/> <xsd:enumeration value="WRITE"/> <xsd:enumeration value="GETOD"/> </xsd:restriction> </xsd:simpleType> The enumeration values of a OperationT enumeration type are described in Table 2. Table 2 – Enumerations of OperationT Enumeration Description READ Read Service according to IEC 61158-5-9:2007, 6.3.5.3.2 WRITE Write Service according to IEC 61158-5-9:2007, 6.3.5.3.3 GETOD GetOD (long form) service according to IEC 61158-5-9:2007, 6.3.2.3.2 B.5 ResponseCodeT A complex type that defines negative response error information. The XML schema for a ResponseCodeT type is: <xsd:complexType name="ResponseCodeT"> <xsd:attribute name="ErrorClass" type="xsd:unsignedShort" use="required"/> <xsd:attribute name="AdditionalCode" type="xsd:short" use="optional"/> <xsd:attribute name="AdditionalDescription" type="xsd:string" use="optional"/> </xsd:complexType> The attributes of a ResponseCodeT type are described in Table 3. Table 3 – Attributes of ResponseCodeT Attribute Description ErrorClass Class of error reported by the negative service response. AdditionalCode Optional reason code provided by the function block application. AdditionalDescription Optional text description of the negative service response. B.6 TransferResultDataT A complex type that defines the service parameter data format that shall be applied to Transfer defined recievedData return value. The XML schema for a TransferResultDataT type is: Next >