IEC 62769-101-2:2023

IEC 62769-101-2 ®
Edition 3.0 2023-04
REDLINE VERSION
INTERNATIONAL
STANDARD
colour
inside ®
Field Device Integration (FDI) –
Part 101-2: Profiles – Foundation Fieldbus HSE

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - webstore.iec.ch/advsearchform IEC Products & Services Portal - products.iec.ch
The advanced search enables to find IEC publications by a Discover our powerful search engine and read freely all the
variety of criteria (reference number, text, technical publications previews. With a subscription you will always have
committee, …). It also gives information on projects, replaced access to up to date content tailored to your needs.
and withdrawn publications.
Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished
The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published
containing more than 22 300 terminological entries in English
details all new publications released. Available online and once
and French, with equivalent terms in 19 additional languages.
a month by email.
Also known as the International Electrotechnical Vocabulary

(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc

If you wish to give us your feedback on this publication or need
further assistance, please contact the Customer Service
Centre: sales@iec.ch.
IEC 62769-101-2 ®
Edition 3.0 2023-04
REDLINE VERSION
INTERNATIONAL
STANDARD
colour
inside ®
Field Device Integration (FDI) –
Part 101-2: Profiles – Foundation Fieldbus HSE
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 25.040.40; 35.100.05 ISBN 978-2-8322-6848-3
– 2 – IEC 62769-101-2:2023 RLV © IEC 2023
CONTENTS
FOREWORD . 4
1 Scope . 6
2 Normative references . 6
3 Terms, definitions, abbreviated terms and conventions acronyms . 7
3.1 Terms and definitions . 7
3.2 Abbreviated terms and acronyms . 7
4 Conventions . 7
4.1 EDDL syntax . 7
4.2 XML syntax . 7
5 Profile for CP 1/2 (FOUNDATION™ HSE) . 8
5.1 General . 8
5.2 Catalog profile . 8
5.2.1 Protocol support file (Capability File) . 8
5.2.2 CommunicationProfile definition . 8
5.2.3 Profile device . 8
5.2.4 Protocol version information . 8
5.3 Associating a Package with a CP 1/2 device . 9
5.3.1 Device type identification mapping . 9
5.3.2 Device type revision mapping . 9
5.4 Information Model mapping . 9
5.4.1 ProtocolType definition . 9
5.4.2 DeviceType mapping . 9
5.4.3 FunctionalGroup Identification definition . 10
5.4.4 BlockType property mapping . 10
5.4.5 Mapping to Block ParameterSet . 11
5.5 Topology elements . 11
5.5.1 ConnectionPoint definition . 11
5.5.2 Communication Device definition . 12
5.5.3 Communication service provider definition . 14
5.5.4 Network definition . 14
5.6 Methods . 15 ®
5.6.1 Methods for FDI Communication Servers . 15
5.6.2 Methods for Gateways . 21
Annex A (normative) Topology scan schema . 22
A.1 General . 22
A.2 Target Namespace . 22
A.3 Network . 22
A.4 FoundationHSEAddressT . 22
A.5 FoundationHSEConnectionPointT . 22
A.6 FoundationHSENetworkT . 23
A.7 FoundationBlockIdentificationT . 24
A.8 FoundationIdentificationT . 24
Annex B (normative) Transfer service parameters . 26
Annex C (informative) Communication service arguments for Transfer Method . 27
Bibliography . 28

Table 1 – Capability File part . 8
Table 2 – CommunicationProfile definition . 8
Table 3 – Device type catalog mapping . 9
Table 4 – ProtocolType Foundation_HSE definition . 9
Table 5 – Inherited DeviceType property mapping . 10
Table 6 – Identification parameters . 10
Table 7 – Inherited BlockType property mapping. 11
Table 8 – ConnectionPointType ConnectionPoint_Foundation_HSE definition. 11
Table 9 – Communication device ParameterSet definition . 14
Table 10 – Method Connect arguments . 16
Table 11 – Method Disconect arguments . 16
Table 12 – Method Transfer arguments . 17
Table 13 – Method GetPublishedData arguments. 19
Table 14 – Method SetAddress arguments . 20
Table A.1 – Attributes of FoundationHSEConnectionPointT . 23
Table A.2 – Elements of FoundationHSEConnectionPointT . 23
Table A.3 – Elements of FoundationHSENetworkT . 24
Table A.4 – Attributes of FoundationBlockIdentificationT. 24
Table A.5 – Attributes of FoundationIdentificationT . 25

– 4 – IEC 62769-101-2:2023 RLV © IEC 2023
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________ ®
FIELD DEVICE INTEGRATION (FDI ) –

Part 101-2: Profiles – Foundation Fieldbus HSE

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Their
preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with
may participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between
any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent
rights. IEC shall not be held responsible for identifying any or all such patent rights.
This redline version of the official IEC Standard allows the user to identify the changes
made to the previous edition IEC 62769-101-2:2020. A vertical bar appears in the margin
wherever a change has been made. Additions are in green text, deletions are in
strikethrough red text.
IEC 62769-101-2 has been prepared by subcommittee 65E: Devices and integration in
enterprise systems, of IEC technical committee 65: Industrial-process measurement, control
and automation. It is an International Standard.
This third edition cancels and replaces the second edition published in 2020. This edition
constitutes a technical revision.
This edition includes the following significant technical changes with respect to the previous
edition:
a) added namespace to Annex A;
b) changed content type of cff file to application/vnd.ff.cff.
The text of this International Standard is based on the following documents:
Draft Report on voting
65E/861/CDV 65E/918/RVC
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this International Standard is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available
at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are
described in greater detail at www.iec.ch/standardsdev/publications.
A list of all parts in the IEC 62769 series, published under the general title Field device ®
integration (FDI ), can be found on the IEC website.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related to
the specific document. At this date, the document will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
IMPORTANT – The "colour inside" logo on the cover page of this document indicates that it
contains colours which are considered to be useful for the correct understanding of its
contents. Users should therefore print this document using a colour printer.

– 6 – IEC 62769-101-2:2023 RLV © IEC 2023 ®
FIELD DEVICE INTEGRATION (FDI ) –

Part 101-2: Profiles – Foundation Fieldbus HSE

1 Scope
This part of IEC 62769 specifies the IEC 62769 profile for IEC 61784-1, CP 1/2 (FOUNDATION™
Fieldbus HSE) .
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies.
For undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC 61784-1, Industrial communication networks – Profiles – Part 1: Fieldbus Profiles
IEC 61784-2, Industrial communication networks – Profiles – Part 2: Additional fieldbus profiles
for real-time networks based on ISO/IEC/IEEE 8802-3
IEC 61804 (all parts), Devices and integration in enterprise systems – Function blocks (FB) for
process control and Electronic Device Description Language (EDDL)
IEC 62541-6, OPC Unified Architecture – Part 6: Mappings
IEC 62541-100:2015, OPC unified architecture – Part 100: Device Interface ®
IEC 62769-2, Field device integration (FDI ) – Part 2: FDI Client ®
IEC 62769-3, Field device integration (FDI ) – Part 3: FDI Server
® ®
IEC 62769-4, Field device integration (FDI ) – Part 4: FDI Packages ®
IEC 62769-5, Field device integration (FDI ) – Part 5: FDI Information Model ®
IEC 62769-6, Field device integration (FDI ) – Part 6: FDI Technology Mapping ®
IEC 62769-7, Field device integration (FDI ) – Part 7: FDI Communication Devices ®
IEC 62769-101-1, Field device integration (FDI ) – Part 101-1: Profiles – Foundation Fieldbus
H1
___________
Foundation™ Fieldbus is the trade name of the non-profit consortium Fieldbus Foundation. This information is
given for the convenience of users of this technical report and does not constitute an endorsement by IEC of the
trademark holder or any of its products. Compliance does not require use of the trade name. Use of the trade
name requires permission of the trade name holder.

3 Terms, definitions, abbreviated terms and conventions acronyms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 61784-1,
IEC 61784-2, IEC 61804 (all parts), IEC 62541-100, IEC 62769-2, IEC 62769-3, IEC 62769-4,
IEC 62769-5, IEC 62769-6, IEC 62769-7 and IEC 62769-101-1 apply.
ISO and IEC maintain terminology databases for use in standardization at the following
addresses:
• ISO Online browsing platform: available at https://www.iso.org/obp
• IEC Electropedia: available at https://www.electropedia.org
3.2 Abbreviated terms and acronyms
For the purposes of this document, the following abbreviations apply:
CFF Common File format
CP communication profile (see IEC 61784-1 or IEC 61784-2)
CPF communication profile family (see IEC 61784-1 or IEC 61784-2)
EDD Electronic Device Description (see IEC 61804 series)
EDDL Electronic Device Description Language (see IEC 61804 series)
FB function block
IM Information Model
SMIB system management information base
VFD virtual field device
4 Conventions
4.1 EDDL syntax
®2
This document specifies content for the EDD component that is part of FDI Communication
Packages. EDDL syntax uses the font Courier New. EDDL syntax is used for method
signature, variable, data structure and component declarations.
4.2 XML syntax
XML syntax examples use the font Courier New. The XML syntax is used to describe XML
document schema.
Example:
___________
FDI is a registered trademark of the non-profit organization Fieldbus Foundation, Inc. This information is given
for the convenience of users of this document and does not constitute an endorsement by IEC of the trademark
holder or any of its products. Compliance does not require use of the trade name. Use of the trade name requires
permission of the trade name holder.

– 8 – IEC 62769-101-2:2023 RLV © IEC 2023
5 Profile for CP 1/2 (FOUNDATION™ HSE)
5.1 General ®
This profile annex specifies the protocol specifics needed for FDI Packages describing
communication servers, gateways and devices. Requirements for Direct Access transfer service
parameters are given in Annex B.
Annex B defines the XML schema for Direct Access Services. Annex C provides an overview of
mapping PROFIBUS standard parameters to PA DIM.
5.2 Catalog profile
5.2.1 Protocol support file (Capability File) ®
Each CP 1/2 FDI Device Package shall contain a capability file. The capability file part is
described in Table 1.
Table 1 – Capability File part
Parameter Description
Content Type txt/plain application/vnd.ff.cff
Root Namespace Not applicable
Source Relationship http://fdi-cooperation.com/2010/relationships/attachment-protocol
Filename Use file extension .CFH

5.2.2 CommunicationProfile definition
IEC 62769-4 defines a CommunicationProfileT string type for the Catalog XML schema. Table 2
defines the CP 1/2 specific values for this string.
Table 2 – CommunicationProfile definition
CommunicationProfile Description
foundation_hse CP 1/2 device type

5.2.3 Profile device
Not supported in this document.
5.2.4 Protocol version information
IEC 62769-4 defines an element type named InterfaceT for the Catalog XML Schema. Element
type InterfaceT contains an element named Version which is supposed to provide version
information about the applied communication protocol profile. The value follows the
IEC 62769-4 defined version information schema defined in element type VersionT.
The major version part of VersionT shall be set to the ITK_VER parameter. The minor and builds
parts shall be set to 0.
EXAMPLE For ITK_VER 5, the value for InterfaceT is 5.0.0.

5.3 Associating a Package with a CP 1/2 device
5.3.1 Device type identification mapping
CP 1/2 device types are uniquely identified by the parameters MANUFAC_ID, DEVICE_TYPE
and DEV_REV found in the Resource Block of the function block VFD. These parameters are ®
used to associate a given device instance to an FDI Device Package. These parameters are ®
mapped to the FDI Device Package Catalog according to Table 3.
Table 3 – Device type catalog mapping
Catalog Element CP Mapping
Manufacturer element of InterfaceT (IEC 62769-4) MANUFAC_ID
String format “0xdddd” where dddd is the
MANUFAC_ID number in hexadecimal format.
DeviceModel element of InterfaceT String format DEVICE_TYPE
“0xdddd” where dddd is the DEVICE_TYPE number in
String format “0xdddd” where dddd is the
hexadecimal format. (IEC 62769-4)
DEVICE_TYPE number in hexadecimal format.
a
DeviceRevision element
DEV_REV
ListOfSupportedDeviceRevisionsT (IEC 62769-4)
String format “x.0.0” where x is the DEV_REV in
decimal format (no leading zeros).
a
Conditional: Shall be available if the device exposes a Function block VFD.

5.3.2 Device type revision mapping
Each device type is identified per 5.3.1. A device may also include a parameter
COMPATIBILITY_REV from the Resource Block. This parameter specifies the lowest device
version (DEV_REV) that a new device can replace while maintaining compatibility with a prior ®
FDI Device Package.
5.4 Information Model mapping
5.4.1 ProtocolType definition
Table 4 defines the ProtocolType used to identify CP 1/2 network communications.
Table 4 – ProtocolType Foundation_HSE definition
Attribute Value
BrowseName Foundation_HSE
IsAbstract False
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Inherits the properties of ProtocolType defined in IEC 62541-100.

5.4.2 DeviceType mapping
Each device type inherits the properties of DeviceType. The mapping of the inherited properties
from DeviceType is defined in Table 5.

– 10 – IEC 62769-101-2:2023 RLV © IEC 2023
Table 5 – Inherited DeviceType property mapping
Property CP Mapping
SerialNumber DEV_ID (System Management Information Base)
RevisionCounter -1 (not defined)
Manufacturer ®
String obtained from FDI package catalog
(ManufacturerName from PackageT)
Model ®
String obtained from FDI package catalog (Name of
DeviceTypeT, which is a localized name)
a
DeviceManual
entry text string (not supported)
b
DeviceRevision
DEV_REV (Resource Block)
SoftwareRevision SOFTWARE_REV (if available, otherwise empty
string)
HardwareRevision HARDWARE_REV (if available, otherwise empty
string)
a ®
Device manuals are exposed as attachments of the FDI Device Package.
b
Conditional: Shall be available if the device exposes a Function block VFD.

5.4.3 FunctionalGroup Identification definition ®
As defined in IEC 62541-100, each device representation in the FDI Server hosted Information
Model shall contain a protocol specific FunctionalGroup called Identification. This
FunctionalGroup organizes variables found in the Resource Block of the device type instance.
The FunctionalGroup Identification for CP 1/2 is defined in Table 6.
Table 6 – Identification parameters
BrowseName VariableType Optional/Mandatory
MANUFAC_ID UInt32 Mandatory
DEV_TYPE UInt16 Mandatory
a
DEV_REV UInt8
Conditional
HARDWARE_REV String Optional
SOFTWARE_REV String Optional
COMPATIBILITY_REV UInt8 Optional
CAPABILITY_LEV UInt8 Optional
a
ITK_VER UInt16
Conditional
SIF_ITK_VER UInt16 Optional
FD_VER UInt16 Optional
a
Conditional: Shall be available if the device exposes a Function block VFD.

5.4.4 BlockType property mapping
CP 1/2 device types are block-oriented according to IEC 62541-100. IEC 62769-5 specifies the
mapping of EDDL BLOCK_A elements to block types and instances.
The BLOCK_A maps as a subtype of the topology element BlockType and inherits the properties
as per IEC 62541-100. The mapping of the inherited properties of BlockType is specified in
Table 7.
Table 7 – Inherited BlockType property mapping
Property CP Mapping (Block’s ParameterSet)
RevisionCounter ST_REV
ActualMode MODE_BLK.ACTUAL
PermittedMode MODE_BLK.PERMITTED
NormalMode MODE_BLK.NORMAL
TargetMode MODE_BLK.TARGET
5.4.5 Mapping to Block ParameterSet
The ParameterSet is relative to each Block. The ParameterSet includes the
CHARACTERISTICS records of the block that contains all the parameters found in the
PARAMETERS, LOCAL_PARAMETERS and LIST_ITEMS.
The browse name of the parameters found in the PARAMETERS and LOCAL_PARAMETERS
is the member name in the respective lists. For example, ST_REV is the browse name of the
Static Revision parameter. LIST_ITEMS do not have member names; therefore, the browse
name of each LIST in the LIST_ITEMS is the item name of the list.
5.5 Topology elements
5.5.1 ConnectionPoint definition
The ConnectionPoint type ConnectionPoint_Foundation_HSE shall be used to identify CP 1/2
network communication and is defined in Table 8. The ConnectionPoint_Foundation_HSE type
is a sub type of the abstract type ConnectionPointType defined in IEC 62541-100.
The Address property can be an IPv4 or IPv6 address. For IPv4 addresses, the address shall
be stored in the last 4 octets and all other octets shall be set to zero.
The OrdinalNumber property reflects the position of the VFD within the SMIB VFD list. For
devices exposing multiple FB VFDs the OrdinalNumber property is mandatory to address the
FB VFD. For devices with a single FB VFD the OrdinalNumber property can be omitted. Devices
exposed as instances of type DeviceType define their Connection points as components. Hence
Devices with multiple FB VFDs shall contain multiple Connection points, one per FB VFD.
Table 8 – ConnectionPointType ConnectionPoint_Foundation_HSE definition
Attribute Value
BrowseName ConnectionPoint_Foundation_HSE
IsAbstract False
References NodeClass BrowseName DataType TypeDefinition ModellingRule
Inherits the properties of ConnectionPointType defined in IEC 62541-100.
HasProperty Variable Address Octet[16] PropertyType Mandatory
HasProperty Variable OrdinalNumber Int32 PropertyType Optional

The ConnectionPoint type ConnectionPoint_Foundation_HSE shall be described by an EDD ®
element contained in a Communication Device related FDI Package that can drive a CP 1/2
network. Actual ConnectionPoint_ConnectionPoint properties are declared by VARIABLE
constructs grouped together in a COLLECTION named
Foundation_HSE_ConnectionPoint_Properties.

– 12 – IEC 62769-101-2:2023 RLV © IEC 2023
COMPONENT ConnectionPoint_Foundation_HSE
{
LABEL "Foundation HSE Connection point";
CLASSIFICATION NETWORK_CONNECTION_POINT;
CAN_DELETE FALSE;
PROTOCOL Foundation_HSE;
CONNECTION_POINT Foundation_HSE_ConnectionPoint_Properties;
}
VARIABLE Address
{
LABEL "Address";
HELP "Address";
CLASS DEVICE;
TYPE OCTET(16);
HANDLING READ & WRITE;
}
VARIABLE OrdinalNumber
{
LABEL "OrdinalNumber address property";
HELP "OrdinalNumber property to address the Function Block
Application”;
CLASS DEVICE;
TYPE UNSIGNED_INTEGER (4);
HANDLING READ & WRITE;
}
COLLECTION Foundation_HSE_ConnectionPoint_Properties
{
LABEL "Foundation HSE Connection Point data";
MEMBERS
{
CONNECTION_POINT_ADDRESS, Address;
CONNECTION_POINT_ORDINALNUMBER, OrdinalNumber;
}
}
5.5.2 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 an FDI
Communication Server.
COMPONENT Foundation_HSE_Communication_Server
{
LABEL "Foundation HSE communication server",
PRODUCT_URI "urn:Fieldbus Foundation:Foundation HSE Communication
Server";
CAN_DELETE TRUE;
CLASSIFICATION NETWORK_COMPONENT;
COMPONENT_RELATIONS
{
Foundation_HSE_Communication_Device_Setup
}
}
COMPONENT_RELATION Foundation_HSE_Communication_Device_Setup
{
LABEL "Relation between Device and communication device";
RELATION_TYPE CHILD_COMPONENT;
COMPONENTS
{
Foundation_HSE_Communication_Device{AUTO_CREATE 1;}
}
MINIMUM_NUMBER 1;
MAXIMUM_NUMBER 1;
}
Semantics of the EDDL constructs shown above are described in IEC 62769-7. The EDDL
® ®
COMPONENT will be utilized by the FDI Server and FDI Communication Server to create an
instance of type CommunicationServerType as described in IEC 62769-7. ®
According to IEC 62769-7, each FDI Communication Package shall contain at least one EDD
element describing at least one CommunicationDevice component. The following EDDL source
code is an example for a communication device.
COMPONENT Foundation_HSE_Communication_Device
{
LABEL "Foundation HSE communication device";
CAN_DELETE TRUE;
CLASSIFICATION NETWORK_COMPONENT;
COMPONENT_RELATIONS
{
Foundation_HSE_Service_Provider_Relation
}
}
COMPONENT_RELATION Foundation_HSE_Service_Provider_Relation
{
LABEL "Foundation HSE communication service provider”;
RELATION_TYPE CHILD_COMPONENT;
COMPONENTS
{
Foundation_HSE_Service_Provider{AUTO_CREATE 1;}
}
MINIMUM_NUMBER 1;
MAXIMUM_NUMBER 16;
}
Semantics of the EDDL constructs shown above are described in IEC 62769-7. The EDDL
® ®
COMPONENT will be utilized by the FDI server and FDI Communication Server to create an
instance of type ServerCommunicationDeviceType as described in IEC 62769-7.
The instance of type ServerCommunicationDeviceType shall contain the following parameter(s)
with its/their ParameterSet. Table 9 shows definition of the Communication device
ParameterSet.
– 14 – IEC 62769-101-2:2023 RLV © IEC 2023
Table 9 – Communication device ParameterSet definition
Attribute Value
BrowseName ParameterSet
References NodeClass BrowseName DataType TypeDefinition ModellingRule
See IEC 62541-100:2015, 5.2.
HasTypeDefinition ObjectType BaseObjectType
HasComponent Variable  BaseDataVariableType Mandatory-
Placeholder
5.5.3 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 is an example for a CP 1/2 communication service provider component.
The component reference ConnectionPoint_Foundation_HSE corresponds to the related
Connection Point definition in 5.4.2.
COMPONENT Foundation_HSE_Service_Provider
{
LABEL "Foundation HSE communication service provider";
CAN_DELETE FALSE;
CLASSIFICATION NETWORK_COMMUNICATION_SERVICE_PROVIDER;
COMPONENT_RELATIONS
{
Foundation_HSE_Connection_Point_Relation
}
BYTE_ORDER BIG_ENDIAN;
}
COMPONENT_RELATION
Foundation_HSE_Service_Provider_Connection_Point_Relation
{
LABEL "Relation between communication service provider and
connection point";
RELATION_TYPE CHILD_COMPONENT;
ADDRESSING {Address}
COMPONENTS
{
ConnectionPoint_Foundation_HSE{ AUTO_CREATE 1;}
}
MINIMUM_NUMBER 1;
MAXIMUM_NUMBER 1;
}
Semantics of the EDDL constructs shown above are described in IEC 62769-7. The EDDL
® ®
COMPONENT will be utilized by the FDI Server and FDI Communication Server to create an
instance of type ServerCommunicationServiceType as described in IEC 62769-7.
5.5.4 Network definition ®
According to IEC 62769-7 each FDI Communication Package shall contain at least 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 Network_Foundation_HSE
{
LABEL "Foundation HSE Network";
CAN_DELETE TRUE;
CLASSIFICATION NETWORK;
COMPONENT_RELATIONS
{
Foundation_HSE_Network_Connection_Point_Relation
}
COMPONENT_RELATION Foundation_HSE_Network_Connection_Point_Relation
{
LABEL "Relation between network and connection point";
RELATION_TYPE CHILD_COMPONENT;
ADDRESSING {Address}
COMPONENTS
{
ConnectionPoint_Foundation_HSE
}
MINIMUM_NUMBER 1;
MAXIMUM_NUMBER 32;
}
Semantics of the EDDL constructs shown above are described in IEC 62769-7. The EDDL
® ®
COMPONENT will be utilized by the FDI server and FDI Communication Server to create an
instance of type NetworkType as described with IEC 62541-100.
5.6 Methods ®
5.6.1 Methods for FDI Communication Servers
5.6.1.1 General
The Communication Server shall implement services according to the method signatures
described in 5.6.1 and according to the Information Model.
5.6.1.2 Connect
Table 10 shows the Method Connect arguments.
Signature:
Connect(
[in] ByteString CommunicationRelationId,
[in] ByteString Address,
[in] Int32 OrdinalNumber,
[out] Int32 ServiceError);
– 16 – IEC 62769-101-2:2023 RLV © IEC 2023
Table 10 – Method Connect arguments
Argument Description
CommunicationRelationId The argument value contains the nodeId of the Device ConnectionPoint
representing the connection between a device and a physical network directly ®
connected to the FDI Communication Server hardware. The nodeId allows
to find the direct parent-child relation.
Address 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.1. The argument value holds the device’s IPv4 or
IPv6 address.
The argument name shall match with the corresponding attribute name
OrdinalNumber
defined for the ConnectionPoint which is described by a corresponding EDD
element specified in 5.5.1. The argument value holds the OrdinalNumber. The
OrdinalNumber is the position of the VFD within the SMIB VFD list. If a value
0 is passed with this argument the first FB VFD is selected.
ServiceError 0: OK / execution finished, connection established successfully
-1: Connect Failed / canceled by caller
-2: Call Failed / unknown service ID
-3: Connect Failed / device not found
-4: Connect Failed / invalid device node address
-5: Connect Failed / invalid device identification
-6: Connect Failed / invalid LinkId argument
-7: Connect Failed / invalid OrdinalNumber argument
NOTE IEC 62769-7 defines the argument AddressData of the Connect Method as an array of Variant. The
address arguments defined with the table are represented as entries of the Variant array in the order they are
specified above. IEC 62769-7 defines the argument DeviceInformation as a protocol specific argument list in which
the Connect Method stores the resulting data. The DeviceInformation argument is defined as an array of Variant.
The DeviceInformation argument is not used.

5.6.1.3 Disconnect
Table 11 shows the Method Disconnect arguments.
Signature:
Disconnect(
[in] ByteString CommunicationRelationId,
[out] UInt32 ServiceError);
Table 11 – Method Disconect arguments
Argument Description
CommunicationRelationId The argument value contains the nodeId of the Device ConnectionPoint
representing the connection between a device and a physical network directly ®
connected to the FDI Communication Server hardware. The nodeId allows
finding 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
Table 12 shows the Method Transfer arguments.

Signature
Transfer(
[in] ByteString CommunicationRelationId,
[in] String OPERATION,
[in] String BlockTag,
[in] UInt32 INDEX,
[in] UInt32 SUB_INDEX,
[in] Byte[] WriteData,
[in] UInt32 ServiceId,
[out] Byte[] ReadData,
[out] Int32 ServiceError);
Table 12 – Method Transfer 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.
OPERATION The argument value indicates the data transfer operation. Allowed values are
“READ”, “WRITE” and “VIEW_READ”.
BlockTag The argument denotes the Block tag of the block instance being addressed.
The value can be obtained by the Method Scan.
INDEX OPERATION indicates “READ” or “WRITE”:
The argument denotes the relative index of the block parameter being
addressed. The relative index can be calculated by iterating the parameters ®
of a block within the FDI Information Model. A value of 0 addresses the
block header record (described by the CHARACTERISTICS attribute within
the EDD). The first parameter is addressed with the INDEX 1.
OPERATION indicates “VIEW_READ”:
The argument denotes the view identifier in a range from 1 to 4. For instance
a value of 1 requests that View_1 shall be read. Multiple View_3 or View_4
objects are identified by the INDEX and the SUB_INDEX argument.
SUB_INDEX OPERATION indicates “READ” or “WRITE”:
The argument denotes the subindex of a member of the block parameter
being addressed if the block parameter is of type RECORD or ARRAY.
To address a simple parameter, a value of 0 shall be passed with this
argument.
To address a specific member of a parameter of type RECORD or ARRAY a
1-relative value shall be passed with this argument.
To address the parameter of type RECORD or ARRAY as a whole a value of
0 shall be passed with this argument.
OPERATION indicates “VIEW_READ”:
The argument addresses a View_3 or View_4 if multiple views of that type
exist. The argument shall be 0 if there are no multiple views of the type
addressed with the INDEX argument. Values of 1 up to the number of views
of that type address the specific view.
WriteData Write data encoded as byte array. Encoding of integers shall follow the rules
defined with IEC 62541-6. The argument shall be ignored if OPERATION
indicates a read transfer or a view read transfer.
ServiceId The service transaction code establishes the relation between the service
request and the corresponding response
ReadData With this argument the read data byte stream is returned as a byte array.
Encoding of integers shall follow the rules defined with IEC 62541-6. The
argument shall be ignored if OPERATION indicates a write transfer.

– 18 – IEC 62769-101-2:2023 RLV © IEC 2023
Argument Description
ServiceError 0: OK / execution finished
-1: Transfer Failed / canceled by caller
-2: Call Failed / unknown service ID
-3: Transfer Failed / no existing communication relation.
-4: Transfer Failed / invalid communication relation identifier
-5: Transfer Failed / invalid sendData content
-6: Transfer Failed / invalid receiveData format
a
-7: Transfer Failed / Parameter Check
a
-8: Transfer Failed / exceeds Parameter Limits
a
-9: Transfer Failed / wrong Mode for Request
-10: Transfer Failed / write is prohibited by write lock switch or write lock
a
Function Block for SIS devices
a
-11: Transfer Failed / data value is never writeable
-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 as 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 in ®
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 with 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 with 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 with the table is represented as 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.
See Annex C on a description how the communication service arguments for Transfer Method are obtained from

the EDD.
5.6.1.5 GetPublishedData
CP 1/2 alerts represent unsolicited messages as defined in IEC 62769-7. Table 13 shows the
arguments of the Method GetPublishedData.
NOTE CP 1/2 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
GetPublishData service. CP 1/2 also uses the term publish to refer to synchronous, network sched
...