< PreviousField Device Integration (FDI) – Part 103-4: Profiles – PROFINET RELEASED FCG TS62769-103-4 , Ed. 1.2.0, 09 Jul 2019 Page 9 of 33 Profile device A Profile Package shall provide the catalog values for profile devices, enabling the FDI Server to leverage a generic device description, if a specific one is not available. The definitions in Table 3 focus on catalog content that is vendor independent. Table 3 – Catalog values for profile devices Element Attribute Content PackageType — Profile Manufacturer — Empty DeviceModel — Allowed profile identifier values (PROFILE_ID) are provided by PROFIBUS & PROFINET International (PI). PI provides and maintains a XML file (Profile_ID_Table) containing the assignment of PROFILE_ID to profiles. It is available at <http://www.profibus.com/IM/Profile_ID_Table.xml> The file can be downloaded by any engineering or service tool whenever it's connected to the Internet. NOTE More information is provided in PI Order No.: 3.502 (I&M Profile) and related profile definitions referred therein. The string format shall be hexadecimal starting with 0x, e.g. ‘0x3D00’. Protocol version information IEC 62769-4 defines an element type named InterfaceT for the Catalog XML schema. The element type InterfaceT contains an element named Version which is supposed to provide version information about the applied communication protocol profile. The value has to follow the IEC 62769-4 defined version information schema defined in the element type VersionT. Table 4 describes how to apply the currently known protocol versions defined by the non-profit consortium PROFIBUS & PROFINET International. The general rule is to apply the value “0” for parts of the version information according to IEC 62769-4 that are not used in currently known protocol versions. Table 4 – Version mapping examples Protocol / Version InterfaceT Version value PROFINET Version 2.3 2.3.0 NOTE 1 This Table is just an example since this document cannot foresee how future protocol versions will be defined. NOTE 2 The currently known PROFINET protocol revision information provides major and minor version information. Leading zeros are not considered in version value evaluation since only the actual decimal values are relevant. 5.3 Associating a Package with a device Device type identification mapping The purpose of a device type identification mapping is to enable FDI host systems to compare the scan result against the topology representation in the Information Model. FDI host systems shall also be enabled to determine the FDI Device Package that fits for a device entry contained in the scan result. This will enable the user of an FDI host system to synchronize the Information Model with the actual installation. The communication server implemented scan service (defined in 5.6.1.7) provides a scan result through an XML document (schema defined in Annex A). Field Device Integration (FDI) – Part 103-4: Profiles – PROFINET RELEASED FCG TS62769-103-4, Ed. 1.2.0, 09 Jul 2019 Page 10 of 33 The Gateway implemented scan service (defined in 5.6.2.7) provides a scan result by means of the Information Model that contains data structures created from EDD content as specified in 5.6.2.7. Common for both ways of presenting the scan result is that scan results contain device type identification and device instance identification. FDI host systems comparing the actual network topology configuration against the topology representation in the Information Model shall be enabled to handle the following situations: a) The physical Device instance identified at a specific device address is not logically present in the Information model (as Instance): Enable the FDI Host system to find the appropriate FDI Device package according to the device catalogue information. b) The physical Device instance identified by the device address is logically present in the Information Model (as Instance): Enable the FDI Host system to compare the device type information presented in the scan result (see the identification in Clause A.5 and 5.6.2.7) and the device type specific information of the Instance present in the Information Model. The FDI Device package contains device type identification information that can be compared to the scan result based on the Catalog Schema in IEC 62769-4 which defines the XML element (simple) type “DeviceModel” and “Manufacturer”. Both types are used in (complex) element types “Protocol” and “RegDeviceType”. As a result of the FDI Package deployment the FDI Package information is then present in the Information Model as specified FunctionalGroup Identification containing VendorID and DeviceID (see 5.4.3). The mapping between different device identification data sources is described in Table 5. Since scan results provided by the Communication Server or Gateway can convey data that is produced by the device (firmware) the device type identification mapping shall be supported by providing corresponding data in the FDI Device Package contained Catalog and Information Model. Table 5 – Device identification information mapping FDI Device Package Information Model Communication Server provided scan result Gateway provided scan result Catalog specified type Manufacturer FunctionalGroup: Identification Browse Name: VendorID Element (path): ConnectionPoint/Identification Attribute: VendorID COLLECTION ConnectionPoint. Identification.VendorID Catalog specified type DeviceModel FunctionalGroup: Identification Browse Name: DeviceID Element (path): ConnectionPoint/Identification Attribute: DeviceID COLLECTION ConnectionPoint. Identification.DeviceID Device type revision mapping IEC 62769-4 envisions a concept that allows determining the compatibility between an FDI Device Package and a Device. IEC 62769-4 specifies a life cycle management process bearing on a single version information provided for the entire device. PROFINET IO related specifications, for example PI Order No.: 2.352:2011 (GSDML) and PI Order No.: 3.502 (I&M), split the device revision into software and hardware related information. These specifications do not outline any rules whether the GSD, GSDML or I&M specified HARDWARE_REVISION is independent from SOFTWARE_REVISION. The goal of 5.3.2 is to describe the translation rules between the PROFINET IO related specifications describing their way of providing version information and the IEC 62769-4 specified way of containing version information Field Device Integration (FDI) – Part 103-4: Profiles – PROFINET RELEASED FCG TS62769-103-4 , Ed. 1.2.0, 09 Jul 2019 Page 11 of 33 that can be compared against the version read from the device. The purpose is to determine compatibility between an FDI Device Package and a Device. (Figure 1 depicts the problem.) FDIPROFINET FDI specified Device revision I&M: HARDWARE_REVISION GSDML: HardwareRelease I&M: SOFTWARE_REVISION GSDML: SoftwareRelease FDI Profile specifed translation Figure 1 – Version mapping problem The firmware of a device implements the data exchange interface which shall be described by means of the FDI Device Package content (EDD). A device firmware that implements the GSD, GSDML or I&M profile enables reading the values SOFTWARE_REVISION and HARDWARE_REVISION. The access to these values shall be described in the FDI Device Package contained EDD. Firmware modifications that affect the firmware implemented data exchange interface shall be reflected in the FDI Device Package. Such firmware and device description modification shall be visible in the SOFTWARE_REVISION. Hardware related modifications shall be captured in the HARDWARE_REVISION value. Hardware related modifications do not necessarily require always a firmware update. Thus HARDWARE_REVISION cannot be used to determine compatibility between a device and the FDI Device Package. But if a hardware modification requires firmware modifications both HARDWARE_REVISION and SOFTWARE_REVISION shall be changed. The IEC 62769-4 specifies the Catalog schema and an element DeviceVersion which is used in the element type declaration ListOfSupportedDeviceVersions. The value of DeviceVersion shall be compared to the device provided SOFTWARE_REVISION in order to determine the compatibility between an FDI Device Package and a Device. The data format for the SOFTWARE_REVISION is a string while the DeviceVersion expects three numbers for major, minor, and revision. Therefore the following rules apply: If the string has the format <integer>.<integer>.<integer> this is transferred to major, minor, and revision (in the same order). <integer> references to simple integer number in the string such as ‘1’ or ‘12’, not to other representations such as hexadecimal format (e.g. 0x001A). If <integer>.<integer> is provided, this is transferred to major and minor and ‘0’ is used for revision. If only an <integer> is provided, this is transferred to major and ‘0’ is used for minor and revision. A leading character or a leading character and whitespace shall be ignored. For a string in any other format the revision number shall not be considered to select the correct FDI package. 5.4 Information Model mapping ProtocolType definition This standard refers to IEC 61158 specified protocols as these are relevant to support the device management related use cases supported through FDI specifications. The scope is limited to data transport from the Information Model to the device. Field Device Integration (FDI) – Part 103-4: Profiles – PROFINET RELEASED FCG TS62769-103-4, Ed. 1.2.0, 09 Jul 2019 Page 12 of 33 For example, the device address management is based on services specified in the IEC 61158 series. But since the address management service is encapsulated by the IEC 62769-7 specified SetAddress service the details of IEC 61158 specified services do not need to be known. The protocol type Profinet_IO shall be used to identify the PROFINET IO communication. The type Profinet_IO is a subtype of the abstract type ProtocolType (IEC 62541-100). Table 6 specifies the attributes and their values of the Protocol type Profinet_IO. Table 6 – Protocol type Profinet_IO Attribute Value BrowseName Profinet_IO IsAbstract False References NodeClass BrowseName DataType TypeDefinition ModellingRule Subtype of the ProtocolType defined in IEC 62541-100. DeviceType mapping The properties mapping of the DeviceType node is defined in Table 7. Table 7 – DeviceType Property mapping Property PROFINET Mapping SerialNumber SERIAL_NUMBER (see Table 8) RevisionCounter REV_COUNTER (see Table 8) Manufacturer String taken from FDI package catalog (ManufacturerName from PackageT) Model String taken from FDI package catalog (Name of DeviceTypeT, which is a localized name) DeviceRevision Not supported DeviceManual Not supported SoftwareRevision SOFTWARE_REVISION (see Table 8) HardwareRevision HARDWARE_REVISION (see Table 8) FunctionalGroup identification definition As defined in IEC 62541-100:–, 5.3, each device representation in the FDI Server hosted Information Model shall contain a protocol specific FunctionalGroup named Identification. The Parameters of this FunctionalGroup are defined for PROFINET as follows: Field Device Integration (FDI) – Part 103-4: Profiles – PROFINET RELEASED FCG TS62769-103-4 , Ed. 1.2.0, 09 Jul 2019 Page 13 of 33 Table 8 – PROFINET identification type definition BrowseName DataType Mandatory/Optional VendorID UInt16 Mandatory DeviceID UInt16 Mandatory ORDER_ID String Mandatory SERIAL_NUMBER String Mandatory HARDWARE_REVISION UInt16 Mandatory SOFTWARE_REVISION String Mandatory REV_COUNTER UInt16 Mandatory PROFILE_ID UInt16 Mandatory PROFILE_SPECIFIC_TYPE UInt16 Mandatory IM_VERSION ByteString Mandatory IM_SUPPORTED UInt16 Mandatory The BaseDataVariable instances shall be created from VARIABLE declarations with identifiers that correspond to the browse names listed in Table 8 except the attributes VendorID and DeviceID. The related attribute values shall be taken from the GSD file (5.2.1). The element names VendorID and DeviceID match with the attribute names defined in the GSDML specification. 5.5 Topology elements ConnectionPoint definition In order to support different network topology engineering needs related to different protocol layers used for PROFINET IO the ConnectionPoint type definitions follow the IEC 62769-7 given recommendations about how to handle address information for protocol layers embedded in PROFINET IO. The ConnectionPoint type ConnectionPoint_Profinet_IO shall be used to parameterize PROFINET IO network access points. The ConnectionPoint type Profinet_IO is a subtype of the abstract type ConnectionPointType (IEC 62769-5). Table 9 specifies the allowed values of the ConnectionPoint attributes for the protocol type Profinet_IO. Table 9 – ConnectionPoint type for Profinet_IO Attribute Value BrowseName Profinet_IO IsAbstract False References NodeClass BrowseName DataType TypeDefinition ModellingRule Subtype of the ConnectionPointType defined in IEC 62541-100. HasProperty Variable MAC Octet[6] PropertyType Mandatory HasProperty Variable IPv4 Octet[4] PropertyType Mandatory HasProperty Variable DNSNAME String PropertyType Mandatory HasProperty Variable VALID Boolean PropertyType Mandatory The ConnectionPoint type Profinet_IO shall be described by an EDD element contained in a Communication Device related FDI Package that can drive a PROFINET IO network. Actual ConnectionPoint properties are declared by VARIABLE constructs grouped together in a COLLECTION named ConnectionPoint. Variable MAC is an array of 6 bytes holding the MAC address. The value is a unique identifier assigned to network interfaces that support IEEE 802.3 specified communication. The value can only be read from the device for example during execution of the scan service. Variable IPv4 is an array of 4 bytes holding the IP-Address. Field Device Integration (FDI) – Part 103-4: Profiles – PROFINET RELEASED FCG TS62769-103-4, Ed. 1.2.0, 09 Jul 2019 Page 14 of 33 NOTE 1 Formatting of an IP-Address results typically in a character string that consists of four “.” separated, 1..3-digit decimal numbers (example 128.12.1.15). The EDDL specification according to IEC 61804-3 and IEC 61804-4 does not support formatting instructions for the OCTECT type. But since semantics of the VARIABLE definitions made in this part of IEC 62769 are defined it’s assumed that system can render VARIABLE values accordingly. Variable DNSNAME holds the station name. The station name syntax shall follow the Domain Name System (DNS) related specifications. NOTE 2 The Domain Name System (DNS) is a hierarchical naming system that translates domain names meaningful to humans into the numerical identifiers associated with networking equipment for the purpose of locating and addressing these devices. The specifications of the rules for forming domain names appear in RFC 1035, RFC 1123 and RFC 2181. The Variable Valid indicates whether the stored address information is valid. COMPONENT ConnectionPoint_PROFINET_IO { LABEL "PROFINET IO Connection point"; CAN_DELETE FALSE; PROTOCOL PROFINET; } VARIABLE MAC { LABEL "MAC address"; HELP "Unique network visible device identifier"; CLASS DEVICE; TYPE OCTET(6); HANDLING READ; CLASS LOCAL; } VARIABLE IPv4 { LABEL "IP Address"; HELP "IP v4 address"; CLASS DEVICE; TYPE OCTET(4); HANDLING READ & WRITE; CLASS LOCAL; } VARIABLE DNS_Name { LABEL "DNS Name"; HELP "Station name"; CLASS DEVICE; TYPE BITSTRING(256); HANDLING READ & WRITE; CLASS LOCAL; } COLLECTION ConnectionPoint { LABEL "PROFINET Connection Point data"; MEMBERS { CONNECTION_POINT_MAC, MAC; CONNECTION_POINT_IPV4, IPv4; CONNECTION_POINT_DNS_NAME, DNS_Name; } } Field Device Integration (FDI) – Part 103-4: Profiles – PROFINET RELEASED FCG TS62769-103-4 , Ed. 1.2.0, 09 Jul 2019 Page 15 of 33 Communication Device definition According to IEC 62769-7 each FDI Communication Package shall contain an EDD element describing the device. The following EDDL source code is an example describing a Communication Server. COMPONENT PROFINET_Communication_Server { LABEL "PROFINET communication server"; PRODUCT_URI "urn:PROFIBUS International: PROFINET Communication Server"; CAN_DELETE TRUE; CLASSIFICATION NETWORK_COMPONENT; COMPONENT_RELATIONS { PROFINET_Communication_Device_Setup } } COMPONENT_RELATION PROFINET_Communication_Device_Setup { LABEL "Relation between Device and communication device"; RELATION_TYPE CHILD_COMPONENT; COMPONENTS { PROFINET_Communication_Device{AUTO_CREATE 1;} } MINIMUM_NUMBER 1; MAXIMUM_NUMBER 2; } According to IEC 62769-7 each FDI Communication Package shall contain at least one EDD element describing at least one communication device component. The following EDDL source code example shows how to describe a PROFINET IO communication device: COMPONENT PROFINET_Communication_Device { LABEL "PROFINET communication device"; CAN_DELETE TRUE; CLASSIFICATION NETWORK_COMPONENT; COMPONENT_RELATIONS { Profinet_Service_Provider_Relation } } COMPONENT_RELATION Profinet_Service_Provider_Relation { LABEL " Relation to communication service provider "; RELATION_TYPE CHILD_COMPONENT; COMPONENTS { PROFINET_Service_Provider{AUTO_CREATE 1;} } MINIMUM_NUMBER 1; MAXIMUM_NUMBER 2; } In an actual communication device the value “Profinet_Service_Provider” needs to be adapted according to the identifier of the COMPONENT declaration that describes the communication service provider. Field Device Integration (FDI) – Part 103-4: Profiles – PROFINET RELEASED FCG TS62769-103-4, Ed. 1.2.0, 09 Jul 2019 Page 16 of 33 Communication service provider definition According to IEC 62769-7 each FDI Communication Package shall contain at least one EDD element describing at least one communication service provider component. The following EDDL source code example shows how to describe a PROFINET IO communication service provider component. The component reference (ConnectionPoint_PROFINET_IO) corresponds to the related connection point definitions given in 5.5. The attribute BYTE_ORDER value is to be set according to the protocol. COMPONENT PROFINET_Service_Provider { LABEL "PROFINET communication service provider"; CAN_DELETE TRUE; CLASSIFICATION NETWORK_COMMUNICATION_SERVICE_PROVIDER; COMPONENT_RELATIONS { PROFINET_Service_Provider_Connection_Point_Relation } BYTE_ORDER BIG_ENDIAN; } COMPONENT_RELATION PROFINET_Service_Provider_Connection_Point_Relation { LABEL "Relation between communication service provider and connection point"; RELATION_TYPE CHILD_COMPONENT; ADDRESSING {DNS_Name} COMPONENTS { ConnectionPoint_PROFINET_IO{ AUTO_CREATE 1;} } MINIMUM_NUMBER 1; MAXIMUM_NUMBER 1; } Network definition According to IEC 62769-7 each FDI Communication Package shall contain at least one EDD element describing network configuration constraints using the component construct. COMPONENT Network_PROFINET { LABEL "PROFINET IO Network"; CAN_DELETE TRUE; CLASSIFICATION NETWORK_COMPONENT; COMPONENT_RELATIONS { PROFINET_IO_Network_Connection_Point_Relation } } COMPONENT_RELATION PROFINET_IO_Network_Connection_Point_Relation { LABEL "Relation between network and connection point"; RELATION_TYPE CHILD_COMPONENT; ADDRESSING {DNS_Name} COMPONENTS { ConnectionPoint_PROFINET_IO } Field Device Integration (FDI) – Part 103-4: Profiles – PROFINET RELEASED FCG TS62769-103-4 , Ed. 1.2.0, 09 Jul 2019 Page 17 of 33 } 5.6 Methods Methods for FDI Communication Servers 5.6.1.1 General The Communication Server contained Information Model shall implement services according to the method signatures described in 5.6.1. 5.6.1.2 Connect Signature: Connect( [in] ByteString CommunicationRelationId, [in] String DNSNAME, [in] UInt16 DeviceID, [in] UInt16 VendorID, [out] Int32 ServiceError); Table 10 provides the description of the arguments. Table 10 – Method Connect arguments Argument Description CommunicationRelationId The argument value contains the nodeId of the ConnectionPoint representing the connection between a device and a physical network which is directly connected to the communication server hardware. The nodeId allows finding the direct parent-child relation. DNSNAME The argument name shall match with the corresponding attribute name defined for the ConnectionPoint which is described by a corresponding EDD element specified in 5.5. The argument value holds the device’s network address. DeviceID The argument value holds the manufacturer defined device identification number. (See GSDML “Attributes of element DeviceIdentity”.) VendorID The argument value holds the PNO defined manufacturer identification number. (See GSDML “Attributes of element DeviceIdentity”.) ServiceError 0: OK / execution finished, connection established successfully -1: Connect Failed / canceled by caller -3: Connect Failed / device not found -4: Connect Failed / invalid device address -5: Connect Failed / invalid DeviceID -6: Connect Failed / invalid ManufacturerID Remarks: The ConnectionPoint defined for PROFINET IO holds more address attribute values than used for the connect service. The reason is that any exchange of record data with the device requires that address assignment is completed. Once address assignment is done the DNSNAME is sufficient to address the device. The MAC address could be used for device type and instance verification purpose but this has been already done during the address assignment. Field Device Integration (FDI) – Part 103-4: Profiles – PROFINET RELEASED FCG TS62769-103-4, Ed. 1.2.0, 09 Jul 2019 Page 18 of 33 5.6.1.3 Disconnect Signature: Disconnect( [in] ByteString CommunicationRelationId, [out] Int32 ServiceError) Table 11 provides the description of the arguments. Table 11 – Method Disconnect arguments Argument Description CommunicationRelationId The argument value contains the nodeId of the ConnectionPoint representing the connection between a device and a physical network which is directly connected to the communication server hardware. The nodeId allows to find the direct parent-child relation. ServiceError 0: OK / disconnect finished successfully -1: Disconnect Failed / no existing communication relation -2: Disconnect Failed / invalid communication relation identifier 5.6.1.4 Transfer Signature Transfer( [in] ByteString CommunicationRelationId, [in] String OPERATION, [in] UInt16 SLOT, [in] UInt16 SUBSLOT, [in] UInt16 INDEX, [in] UInt32 API, [in] ByteString REQUEST, [out] ByteString REPLY, [out] ByteString RESPONSE_CODES [out] Int32 ServiceError); Table 12 provides the description of the arguments. Next >