IEC TS 62453-53-31:2025

IEC TS 62453-53-31 ®
Edition 1.0 2025-03
TECHNICAL
SPECIFICATION
Field Device Tool (FDT) Interface Specification –
Part 53-31: Communication implementation for CLI and HTML – IEC 61784 CP 3/1
and CP 3/2
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, graphical symbols and the glossary.
committee, …). It also gives information on projects, replaced With a subscription you will always have access to up to date
and withdrawn publications. content tailored to your needs.

IEC Just Published - webstore.iec.ch/justpublished
Electropedia - www.electropedia.org
Stay up to date on all new IEC publications. Just Published
The world's leading online dictionary on electrotechnology,
details all new publications released. Available online and once
containing more than 22 500 terminological entries in English
a month by email.
and French, with equivalent terms in 25 additional languages.

Also known as the International Electrotechnical Vocabulary
IEC Customer Service Centre - webstore.iec.ch/csc
(IEV) online.
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 TS 62453-53-31 ®
Edition 1.0 2025-03
TECHNICAL
SPECIFICATION
Field Device Tool (FDT) Interface Specification –

Part 53-31: Communication implementation for CLI and HTML – IEC 61784 CP

3/1 and CP 3/2
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 25.040.40; 35.100.05; 35.110 ISBN 978-2-8327-0283-3

– 2 – IEC TS 62453-53-31:2025 © IEC 2025
CONTENTS
FOREWORD . 6
INTRODUCTION . 8
1 Scope . 9
2 Normative references . 9
3 Terms, definitions, abbreviated terms and conventions . 10
3.1 Terms and definitions . 10
3.2 Abbreviated terms. 11
3.3 Conventions . 11
3.3.1 Data names and references to datatypes . 11
3.3.2 Further conventions . 11
3.3.3 Use of UML . 11
4 Bus category . 11
5 Access to instance, device and process data . 12
5.1 General . 12
5.2 IO signals provided by DTM . 12
5.3 Data interfaces . 12
5.3.1 General. 12
5.3.2 Mapping of PROFIBUS datatypes to FDT datatypes . 12
5.3.3 SemanticInfo . 13
6 Protocol specific behaviour . 16
6.1 PROFIBUS device model . 16
6.2 Configuration and parameterization of PROFIBUS devices. 17
6.2.1 General. 17
6.2.2 Monolithic DTM for a modular PROFIBUS device . 17
6.2.3 Composite DTM for a modular PROFIBUS device. 17
6.3 Support for DP-V0 configuration . 18
6.4 PROFIBUS slaves operating without a class 1 PROFIBUS master . 18
6.5 PROFIBUS-related information of a slave DTM . 19
6.5.1 General. 19
6.5.2 PROFIBUS Network Data (PND) . 19
6.5.3 GSD Information . 27
6.5.4 Process Data Items . 29
7 Protocol-specific usage of general IEC TS 62453-43 datatypes . 29
7.1 General datatypes . 29
7.2 Protocol specific handling of the datatype STRING. 29
8 Network management datatypes. 30
8.1 General . 30
8.2 Configuration . 30
8.3 Process Data Items . 31
8.4 Parameterization . 31
9 Communication datatypes. 31
9.1 General . 31
9.2 ProfibusAbortMessage . 31
9.3 DP-V0 Communication . 32
9.3.1 General. 32
9.3.2 Dpv0ConnectRequest . 33

9.3.3 Dpv0ConnectResponse . 34
9.3.4 Dpv0DisconnectRequest . 34
9.3.5 Dpv0DisconnectResponse . 35
9.3.6 Dpv0TransactionRequest . 36
9.3.7 Dpv0TransactionResponse . 40
9.4 DP-V1 Communication . 46
9.4.1 Dpv1ConnectRequest . 46
9.4.2 Dpv1ConnectResponse . 47
9.4.3 Dpv1DisconnectRequest . 48
9.4.4 Dpv1DisconnectResponse . 49
9.4.5 Dpv1TransactionRequest . 49
9.4.6 Dpv1TransactionResponse . 51
9.5 Error information provided by Communication Channel . 52
10 Datatypes for process data information . 53
10.1 General . 53
10.2 ProfibusIOSignalInfo . 53
11 Device identification . 54
11.1 General . 54
11.2 ProfibusDeviceScanInfo datatype . 55
11.2.1 General. 55
11.2.2 Datatypes derived from ProfibusBaseScanInfo . 56
11.3 ProfibusDeviceIdentInfo datatype . 58
11.3.1 General. 58
11.3.2 Datatypes derived from ProfibusBaseIdentInfo . 60
11.4 Mapping of Information Source. 62
Bibliography . 68

Figure 1 – Relation of IEC TS 62453-53-31 to the IEC 62453 series . 8
Figure 2 – FDT PROFIBUS Device Model . 16
Figure 3 – ProfibusNetworkData. 30
Figure 4 – ProfibusAbortMessage . 32
Figure 5 – Dpv0ConnectRequest . 33
Figure 6 – Dpv0ConnectResponse . 34
Figure 7 – Dpv0DisconnectRequest . 35
Figure 8 – Dpv0DisconnectResponse . 35
Figure 9 – Dpv0ReadConfigurationDataRequest . 36
Figure 10 – Dpv0ReadDiagnosisDataRequest . 37
Figure 11 – Dpv0ReadInputDataRequest . 37
Figure 12 – Dpv0ReadOutputDataRequest . 38
Figure 13 – Dpv0ReadUserParameterRequest. 39
Figure 14 – Dpv0WriteOutputDataRequest . 39
Figure 15 – Dpv0WriteUserParameterRequest. 40
Figure 16 – Dpv0ReadConfigurationDataResponse . 41
Figure 17 – Dpv0ReadDiagnosisDataResponse . 42
Figure 18 – Dpv0ReadInputDataResponse . 42
Figure 19 – Dpv0ReadOutputDataResponse . 43

– 4 – IEC TS 62453-53-31:2025 © IEC 2025
Figure 20 – Dpv0ReadUserParameterResponse . 44
Figure 21 – Dpv0WriteOutputDataResponse . 45
Figure 22 – Dpv0WriteUserParameterResponse . 45
Figure 23 – Dpv1ConnectRequest . 46
Figure 24 – Dpv1ConnectResponse . 47
Figure 25 – Dpv1DisconnectRequest . 48
Figure 26 – Dpv1DisconnectResponse . 49
Figure 27 – Dpv1ReadRequest . 50
Figure 28 – Dpv1WriteRequest . 50
Figure 29 – Dpv1ReadResponse . 51
Figure 30 – Dpv1WriteResponse . 52
Figure 31 – ProfibusIOSignalInfo . 53
Figure 32 – ProfibusDeviceScanInfo . 55
Figure 33 – Datatypes derived from ProfibusBaseScanInfo . 57
Figure 34 – ProfibusDeviceIdentInfo . 59
Figure 35 – Datatypes derived from ProfibusBaseIdentInfo . 60

Table 1 – Mapping of datatypes . 12
Table 2 – Usage of SemanticInfo . 14
Table 3 – PROFIBUS Network Information . 21
Table 4 – Language mapping of GSD file extensions . 28
Table 5 – Protocol-specific sage of general datatypes . 29
Table 6 – ProfibusAbortMessage datatype . 32
Table 7 – Availability of services for Master Class 1 (C1) . 32
Table 8 – Availability of services for Master Class 2 (C2) . 33
Table 9 – Dpv0ConnectRequest datatype . 34
Table 10 – Dpv0ConnectResponse datatype . 34
Table 11 – Dpv0DisconnectRequest datatype . 35
Table 12 – Dpv0DisconnectResponse datatype . 35
Table 13 – Dpv0ReadConfigurationDataRequest datatype . 36
Table 14 – Dpv0ReadDiagnosisDataRequest datatype . 37
Table 15 – Dpv0ReadInputDataRequest datatype . 38
Table 16 – Dpv0ReadOutputDataRequest datatype . 38
Table 17 – Dpv0ReadUserParameterRequest datatype . 39
Table 18 – Dpv0WriteOutputDataRequest datatype . 40
Table 19 – Dpv0WriteUserParameterRequest datatype . 40
Table 20 – Dpv0ReadConfigurationDataResponse datatype . 41
Table 21 – Dpv0ReadDiagnosisDataResponse datatype . 42
Table 22 – Dpv0ReadInputDataResponse datatype . 43
Table 23 – Dpv0ReadOutputDataResponse datatype . 43
Table 24 – Dpv0ReadUserParameterResponse datatype . 44
Table 25 – Dpv0WriteOutputDataResponse datatype . 45
Table 26 – Dpv0WriteUserParameterResponse datatype . 46

Table 27 – Dpv1ConnectRequest datatype . 47
Table 28 – Dpv1ConnectResponse datatype . 48
Table 29 – Dpv1DisconnectRequest datatype . 49
Table 30 – Dpv1DisconnectResponse datatype . 49
Table 31 – Dpv1ReadRequest datatype . 50
Table 32 – Dpv1WriteRequest datatype . 51
Table 33 – Dpv1ReadResponse datatype . 51
Table 34 – Dpv1WriteResponse datatype . 52
Table 35 – ProfibusIOSignalInfo datatype . 54
Table 36 – ProfibusDeviceScanInfo datatype . 56
Table 37 – Datatypes derived from ProfibusBaseScanInfo . 57
Table 38 – ProfibusDeviceIdentInfo datatype . 59
Table 39 – Datatypes derived from ProfibusBaseIdentInfo . 61
Table 40 – Profile specific mapping of identity information . 63

– 6 – IEC TS 62453-53-31:2025 © IEC 2025
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
FIELD DEVICE TOOL (FDT) INTERFACE SPECIFICATION –

Part 53-31: Communication implementation for CLI and HTML –
IEC 61784 CP 3/1 and CP 3/2
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) IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in
respect thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s), which
may be required to implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at https://patents.iec.ch. IEC
shall not be held responsible for identifying any or all such patent rights.
IEC TS 62453-53-31 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 a Technical Specification.
The text of this Technical Specification is based on the following documents:
Draft Report on voting
65E/1110/DTS 65E/1161/RVDTS
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 Technical Specification 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 62453 series, published under the general title Field device tool
(FDT) interface specification, 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 webstore.iec.ch in the data related to the
specific document. At this date, the document will be
• reconfirmed,
• withdrawn, or
• revised.
– 8 – IEC TS 62453-53-31:2025 © IEC 2025
INTRODUCTION
This part of IEC 62453 is an interface specification for developers of Field Device Tool (FDT)
components for function control and data access within a client/server architecture. The
specification is a result of an analysis and design process to develop standard interfaces to
facilitate the development of servers and clients by multiple vendors that need to interoperate
seamlessly.
With the integration of fieldbuses into control systems, there are a few other tasks which need
to be performed. In addition to fieldbus- and device-specific tools, there is a need to integrate
these tools into higher-level system-wide planning or engineering tools. In particular, for use in
extensive and heterogeneous control systems, typically in the area of the process industry, the
unambiguous definition of engineering interfaces that are easy to use for all those involved is
of great importance.
A device-specific software component, called Device Type Manager (DTM), is supplied by the
field device manufacturer with its device. The DTM is integrated into engineering tools via the
FDT interfaces defined in this specification. The approach to integration is in general open for
all kind of fieldbuses and thus meets the requirements for integrating different kinds of devices
into heterogeneous control systems.
Figure 1 shows how this part of the IEC 62453-53-xy series is aligned in the structure of the
IEC 62453 series.
Part 53-31
Communication
implementation
for CLI and HTML –
IEC 61784 CP 3/1
and CP 3/2
Figure 1 – Relation of IEC TS 62453-53-31 to the IEC 62453 series

FIELD DEVICE TOOL (FDT) INTERFACE SPECIFICATION –

Part 53-31: Communication implementation for CLI and HTML –
IEC 61784 CP 3/1 and CP 3/2
1 Scope
This part of the IEC 62453-53-xy series, which is a Technical Specification, provides information
for integrating the PROFIBUS technology into the CLI-based implementation of FDT interface
specification (IEC TS 62453-43).
This document specifies implementation of communication and other services based on
IEC 62453-303-1.
This document neither contains the FDT specification nor modifies it.
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 61158 (all parts), Industrial communication networks – Fieldbus specifications
IEC 61784 (all parts), Industrial communication networks – Profiles
IEC 62453-1, Field device tool (FDT) interface specification – Part 1: Overview and guidance
IEC 62453-2, Field device tool (FDT) interface specification – Part 2: Concepts and detailed
description
IEC TS 62453-43, Field device tool (FDT) interface specification – Part 43: Object model
integration profile – CLI and HTML
IEC 62453-303-1, Field device tool (FDT) interface specification – Part 303-1: Communication
profile integration – IEC 61784 CP 3/1 and CP 3/2
___________
PROFIBUS™ is a trade name of the non-profit organization PROFIBUS Nutzerorganisation e.V. (PNO). This
information is given for the convenience of users of this document and does not constitute an endorsement by
IEC of the trade name holder or any of its products. Compliance to this document does not require use of the
registered logos for PROFIBUS™. Use of the registered logos for PROFIBUS™ requires permission of PNO.

– 10 – IEC TS 62453-53-31:2025 © IEC 2025
3 Terms, definitions, abbreviated terms and conventions
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 62453-1,
IEC 62453-2, IEC TS 62453-43, and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1.1
bus interface module
module of a field device that provides the connection to the fieldbus
3.1.2
CP 3/1
Communication profile of PROFIBUS DP, featuring asynchronous transmission, RS-485
(ANSI TIA/EIA RS-485-A), optional RS-485-IS, plastic fiber, glass multi mode fiber or glass
single mode fiber and PCF fiber
3.1.3
CP 3/2
Communication profile of PROFIBUS PA, featuring synchronous transmission, Manchester
coded, Bus Powered (MBP), optional intrinsically safe (MBP-IS) and lower power (MBP-LP)
3.1.4
Master Class 1
master with control capability
Note 1 to entry: In a DP-V0 environment, depending on the situation, the underlying master device may have either
Master Class 1 (DPM1) functionality or Master Class 2 (DPM2) functionality. A Class 1 master can write output data
to a device and control data exchange.
3.1.5
Master Class 2
master without control capability
Note 1 to entry: In a DP-V0 environment, depending on the situation, the underlying master device may have either
Master Class 1 (DPM1) functionality or Master Class 2 (DPM2) functionality. A Class 2 master can only read the
output data.
3.2 Abbreviated terms
ANSI American National Standards Institute (http://www.ansi.org)
BIM Bus Interface Module
CFG Configuration data used during initialization of PROFIBUS slave device
DCS Distributed Control System
DP Decentralized Peripherals
EIA Electronic Industries Alliance
FDL Fieldbus Data Link layer
FMA Fieldbus Management layer
FMS Fieldbus Message Specification
GSD General Station Description
MBP Manchester coded Bus Powered
PND PROFIBUS Network Data
I&M Identification and maintenance functions
PA Process Automation
PCF Polymer Clad Fibre
PROFIBUS Process FieldBus
RS Radio Sector / Recommended Standard
TIA Telecommunications Industry Association
UML Unified Modeling Language
3.3 Conventions
3.3.1 Data names and references to datatypes
The conventions for naming and referencing of datatypes are explained in IEC TS 62453-43.
3.3.2 Further conventions
Further conventions are:
Convention Indicates
Angle brackets are used to indicate a reference to an asynchronous method.

3.3.3 Use of UML
Figures in this document are using UML notation as defined in IEC 62453-1.
4 Bus category
IEC 61784 CP 3/1 and IEC 61784 CP 3/2 protocols are identified in the attribute ProtocolId of
the BusCategory element by the identifiers, as specified in IEC 62453-303-1.
The supported PhysicalLayer are identified by the Identifier values as specified in
IEC 62453-303-1.
The supported DataLinkLayer are identified by the Identifier values as specified in
IEC 62453-303-1.
– 12 – IEC TS 62453-53-31:2025 © IEC 2025
5 Access to instance, device and process data
5.1 General
The minimum set of data provided by a DTM shall be:
• All device parameters of the Physical Block and Out value of the Function Blocks shall
be exposed via the data interfaces (PROFIBUS PA devices).
• All process values available for the device shall be modelled as ProcessData including
the ranges and scaling if applicable.
• All network configuration related parameters shall be exposed in NetworkData (see
Clause 8).
5.2 IO signals provided by DTM
A DTM shall provide IO signal information for the device using the IProcessData interface. The
IO signals describe datatype and address parameters of process data as detailed in Clause 10.
5.3 Data interfaces
5.3.1 General
Via the interfaces IDeviceData and IInstanceData all device specific parameters shall be
exposed.
5.3.2 Mapping of PROFIBUS datatypes to FDT datatypes
PROFIBUS uses datatypes as specified in the IEC 61158 series for the transmission on the
fieldbus. The FDT interfaces IDeviceData and IInstanceData use .NET datatypes, while PLC
applications use datatypes defined in IEC 61131-3. Hence a mapping between these three type
systems is defined in Table 1.
Table 1 – Mapping of datatypes
PROFIBUS datatype FDT datatype IEC 61131
datatype
Bit information
Boolean BooleanValue BOOL
Unsigned8 BinaryBitArrayValue[8] BYTE
Unsigned16 BinaryBitArrayValue[16] WORD
Unsigned32 BinaryBitArrayValue[32] DWORD
Numeric information with and without sign
Integer8 SignedByteValue SINT
Integer16 IntValue INT
Integer32 LongValue DINT
Unsigned8 ByteValue USINT
Unsigned16 UIntValue UINT
Unsigned32 ULongValue UDINT
Float32 FloatValue REAL
Float64 DoubleValue LREAL
Printable characters (e.g. text)
Visible String StringValue STRING
Unicode String StringValue WSTRING

PROFIBUS datatype FDT datatype IEC 61131
datatype
Time information
TimeDifference without Date Indication TimeSpanValue TIME
Date DateValue DATE
Time Of Day without date indication TimeValue TIME_OF_DAY
Time of Day with date indication DateTimeValue DATE_AND_TIME
Combinations of basic datatypes
Octet String BinaryByteArrayValue ARRAY
ARRAY StructDataGroup ARRAY
STRUCT OF StructDataGroup STRUCT

The FDT datatypes are used by the and methods in the interfaces
IInstanceData and IDeviceData.
5.3.3 SemanticInfo
The identifier in SemanticId shall be unique and always reference the same element (see
Table 2). This means the semantic information shall be the same whenever the same data is
referenced. By using this attribute, for example a Frame Application is able to get the
information regarding the meaning and usage of a single data structure.

– 14 – IEC TS 62453-53-31:2025 © IEC 2025
Table 2 – Usage of SemanticInfo
Attribute Description for use in PROFIBUS
SemanticInfo.ReadParameterAddress For PROFIBUS, ReadParameterAddress and WriteParameterAddress are
SemanticInfo.WriteParameterAddress always identical. The address string shall be constructed according to
the rules of the FDT SemanticId.
PROFIBUS Parameter Address:
The property ‘Address’ follows the different device models that are
defined for PROFIBUS devices. FDT currently supports the following
models:
– PROFIBUS DP / DP-V1,
– PROFIBUS PA,
– PROFIdrive (greater or equal profile version 3)
PROFIBUS DP / DP-V1
The device model is based on devices that are composed of slots,
whereas slots do not necessarily represent physical objects. The data
that is contained in the slots are addressable via Indexes. This data may
be variables or composed blocks of data.
The Address property is APIxxSLOTyyINDEXzz
xx – API
yy – Slot
zz – Index
xx, yy, zz are based on decimal format without leading ‘0’.
PROFIBUS PA
The device is represented by a device management structure and a
number of blocks that provide different functionality (physical block,
function block, transducer block). The blocks are mapped to slot
addresses, but this mapping may vary depending on the device type.
The Address property is APIxxSLOTyyINDEXzz
xx – API
yy – Slot
zz – Index
xx, yy, zz are based on decimal format without leading ‘0’
PROFIdrive
According to the PROFIdrive profile [6], a device (drive unit) may be
composed by a number (1.many) of drive objects (DOs). The DOs may
have different type. Each DO is uniquely identifiable and manages its
own parameters. Each parameter can be uniquely identified by its
number (PNU). Each DO has its own number space.
A parameter may contain simple data or composed data (e.g. arrays).
The data of the device are accessible via a parameter channel (normally
slot 0 index 47).
The Address property is APIxxSLOTyyINDEXzz.DOdo-id.pnu
xx – API
yy – Slot
zz – Index
do-id – Drive Object ID
pnu – ParameterNumber
xx, yy, zz, do-id, pnu are based on decimal format without leading ‘0’.

Attribute Description for use in PROFIBUS
SemanticInfo.ApplicationDomain/ The SemanticIDs for PROFIBUS follow the different device models that
SemanticInfo.SemanticId are defined for PROFIBUS devices. FDT currently supports the following
models:
– PROFIBUS DP,
– PROFIBUS PA,
– PROFIdrive.
PROFIBUS DP / DP-V1
The ApplicationDomain is: FDT_PROFIBUS_DPV1
The device model is based on devices that are composed of slots,
whereas slots do not necessarily represent physical objects. The data
that is contained in the slots are addressable via Indexes. This data may
be variables or composed blocks of data.
The SemanticId for devices not based on a profile is directly based on
the PROFIBUS address information:
The SemanticId is: APIxx.SLOTyy.INDEXzz
xx – AP
yy – Slot
zz – Index
xx, yy, zz are based on decimal format without leading ‘0’
PROFIBUS PA
The ApplicationDomain is: FDT_PROFIBUS_PA
The device is represented by a device management structure and a
number of blocks that provide different functionality (physical block,
function block, transducer block). The blocks are mapped to slot
addresses, but this mapping may vary depending on the device type.
Since the device model is based on blocks, the SemanticIds also are
based on the block model. Within each block, the data is identifiable by
names of parameters.
The SemanticId for PROFIBUS profile related parameter follows the
following rules:
– the SemanticId shall be built based on the names defined in the
profiles
– structured parameters shall be combined with a ‘.’;
– spaces within the profile definition shall be exchanged with an
underscore;
– blocks shall be counted according to the Object Dictionary;
– the block number shall be part of the SemanticId.
The SemanticId is
BlockType.BlockIndex.NameOfParameter.AttributeOfParameter
Example
AnalogInputFB.3.OUT.Unit
PROFIdrive
The ApplicationDomain is: FDT_PROFIBUS_PROFIDRIVE
According to the PROFIdrive profile, a device (drive unit) may be
composed by a number (1.many) of drive objects (DOs). The DOs may
have different types. Each DO is uniquely identifiable and manages its
own parameters. Each parameter can be uniquely identified by its
number (PNU). Each DO has its own number space.
A parameter may contain simple data or composed data (e.g. arrays).
The data of the device are accessible via a parameter channel (slot 0,
index 47).
The SemanticId is: DOdo-id.PNUpnu
do-id – Drive Object ID
pnu – ParameterNumber
do-id, pnu are based on decimal format without leading ‘0’
Example
DO3.PNU64
– 16 – IEC TS 62453-53-31:2025 © IEC 2025
6 Protocol specific behaviour
6.1 PROFIBUS device model
The definition of Process Data Items for the description of I/O values shall be structured
according to the PROFIBUS device model (see Figure 2).

Figure 2 – FDT PROFIBUS Device Model
DTMs for PROFIBUS devices shall provide information about their I/O data to provide
engineering systems knowledge to access such data without the use of the DTMs.

6.2 Configuration and parameterization of PROFIBUS devices
6.2.1 General
In a GSD-based configuration tool the user defines the configuration and sets the appropriate
parameters for the modules. The configuration tool creates the configuration string and the
parameter string that are used to set up the slave properly.
With FDT the configuration and parameterization of the devices is no longer executed only by
a central piece of software; it moves partly into the DTMs. A Device DTM is responsible for
providing configuration and parameterization information for a PROFIBUS master that puts the
PROFIBUS slaves in operation.
A Device DTM is used to adjust a field device to its specific application. Within PROFIBUS,
there are three different aspects of adjustment:
• Communication parameterization: User Prm Data (used in the PROFIBUS service Set_Prm
for setting up the cyclic communication and the specific behaviour of the device).
• Configuration data: Cfg Data (used in the PROFIBUS service Chk_Cfg for definition of the
format and length of the input/output data that are transmitted within cyclic communication).
• Application parameterization: application specific parameters (transmitted via acyclic
read/write PROFIBUS services).
The application parameterization transmitted via acyclic communication is not in the scope of
this document. The parameter data transmitted for this purpose is device specific. Only the
communication services that can be used by Device DTMs for performing such device specific
parameterization are defined. Within this document the term parameterization represents
communication parameterization (Set_Prm).
6.2.2 Monolithic DTM for a modular PROFIBUS device
A monolithic DTM is one single DTM that represents the complete device with its Bus Interface
Module (BIM) and its I/O modules. In general, such a DTM offers a configuration user interface
(presentation object) that allows definition of the used BIM and module types.
Not all PROFIBUS devices require a configuration user interface. That is why not all DTMs
provide the configuration function (ApplicationID: Configuration). This is valid only for non-
modular PROFIBUS devices if the User Prm Data cannot be changed.
The configuration dialog shall allow changing the data only in offline mode if the data set can
be locked.
6.2.3 Composite DTM for a modular PROFIBUS device
Separate DTMs represent the BIM (Composite Device DTM) and the particular I/O modules
(Module DTMs). The effort developing such a modular DTM is normally higher than in the case
of a monolithic DTM, because:
• a private protocol shall be implemented between BIM and I/O modules to ensure that only
a Module DTM can be added to the BIM DTM. This requires an own FDT protocol ID and
the adaptation / creation of FDT communication datatypes.

– 18 – IEC TS 62453-53-31:2025 © IEC 2025
Implementing a Modular DTM results in the following advantages:
– the project topology represents the device structure;
– the user is able to access module-related information directly as a function of the Module
DTM;
– IEC 62453 defines a mechanism to identify DTMs. With these mechanisms it is possible to
provide support for scanning the modules below the BIM and generate the topology
automatically;
– supporting a new type of BIM or I/O module requires an additional DTM “only” and does not
affect existing components. This may result in reduced test effort that can also simplify the
certification process.
The configuration data to set up the PROFIBUS configuration of a modular PROFIBUS device
shall be provided by the Device DTM representing
...