CLC/TR 62453-51-31:2019

SLOVENSKI STANDARD
01-junij-2019
Specifikacija vmesnika orodja procesne naprave - 51-31. del: Implementacija
komunikacije za skupni model objekta - IEC 61784 CP 3/1 in CP 3/2 (IEC/TR 62453-
51-31:2017)
Field device tool (FDT) interface specification - Part 51-31: Communication
implementation for common object model - IEC 61784 CP 3/1 and CP 3/2 (IEC/TR
62453-51-31:2017)
Field Device Tool (FDT)-Schnittstellenspezifikation - Teil 51-31:
Kommunikationsimplementierung mit dem allgemeinen Objektmodell (COM) -
Kommunikationsprofilfamilie (CPF) 3/1 und 3/2 nach IEC 61784 (IEC/TR 62453-51-
31:2017)
Spécification des interfaces des outils des dispositifs de terrain (FDT) - Partie 51-31:
Mise en oeuvre d'un profil de communication pour le modèle d'objet commun - CP 3/1 et
CP 3/2 de l'IEC 61784 (IEC/TR 62453-51-31:2017)
Ta slovenski standard je istoveten z: CLC/TR 62453-51-31:2019
ICS:
25.040.40 Merjenje in krmiljenje Industrial process
industrijskih postopkov measurement and control
35.240.50 Uporabniške rešitve IT v IT applications in industry
industriji
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL REPORT CLC/TR 62453-51-31

RAPPORT TECHNIQUE
TECHNISCHER BERICHT
February 2019
ICS 25.040.40; 35.110
English Version
Field device tool (FDT) interface specification - Part 51-31:
Communication implementation for common object model - IEC
61784 CP 3/1 and CP 3/2
(IEC/TR 62453-51-31:2017)
Spécification des interfaces des outils des dispositifs de Field Device Tool (FDT)-Schnittstellenspezifikation - Teil
terrain (FDT) - Partie 51-31: Mise en œuvre d'un profil de 51-31: Kommunikationsimplementierung mit dem
communication pour le modèle d'objet commun - CP 3/1 et allgemeinen Objektmodell (COM) -
CP 3/2 de l'IEC 61784 Kommunikationsprofilfamilie (CPF) 3/1 und 3/2 nach IEC
(IEC/TR 62453-51-31:2017) 61784
(IEC/TR 62453-51-31:2017)
This Technical Report was approved by CENELEC on 2019-01-07.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden,
Switzerland, Turkey and the United Kingdom.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2019 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. CLC/TR 62453-51-31:2019 E

European foreword
This document (CLC/TR 62453-51-31:2019) consists of the text of the IEC/TR 62453-51-31:2017
prepared by IEC/TC 65 "Industrial-process measurement, control and automation".
Endorsement notice
The text of the International Standard IEC/TR 62453-51-31:2017 was approved by CENELEC as a
European Standard without any modification.

Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications
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.
NOTE 1 When an International Publication has been modified by common modifications, indicated by (mod), the relevant

EN/HD applies.
NOTE 2 Up-to-date information on the latest versions of the European Standards listed in this annex is available here:
www.cenelec.eu.
Publication Year Title EN/HD Year
IEC 61158 Series Industrial communication networks - Fieldbus EN 61158 Series
specifications
IEC 61784-1 2014 Industrial communication networks - Profiles - EN 61784-1 2014
Part 1: Fieldbus profiles
IEC 62453-1 2016 Field device tool (FDT) interface specification EN 62453-1 2017
- Part 1: Overview and guidance
IEC 62453-2 2016 Field device tool (FDT) interface specification EN 62453-2 2017
- Part 2: Concepts and detailed description
IEC/TR 62453-41 2016 Field device tool (FDT) interface specification - -
- Part 41: Object model integration profile -
Common object model
IEC 62453-303-1 2009 Field device tool (FDT) interface specification EN 62453-303-1 2009
+ A1 2016 - Part 303-1: Communication profile + A1 2018
integration - IEC 61784 CP 3/1 and CP 3/2

IEC TR 62453-51-31 ®
Edition 1.0 2017-06
TECHNICAL
REPORT
colour
inside
Field device tool (FDT) interface specification –

Part 51-31: Communication implementation for common object model –

IEC 61784 CP 3/1 and CP 3/2
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 25.040.40; 35.110.05; 35.110 ISBN 978-2-8322-4324-4

– 2 – IEC TR 62453-51-31:2017 © IEC 2017
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 7
2 Normative references . 7
3 Terms, definitions, symbols, abbreviated terms and conventions . 7
3.1 Terms and definitions . 7
3.2 Symbols and abbreviated terms . 8
3.3 Conventions . 8
3.3.1 Data type names and references to data types . 8
3.3.2 Vocabulary for requirements . 8
4 Bus category . 8
5 Access to instance and device data . 8
6 Protocol specific behaviour . 8
6.1 General . 8
6.2 Representing modularity . 9
6.2.1 Monolithic DTMs . 9
6.2.2 Composite Device DTMs . 10
6.3 Interfaces and information related to Bus Master Configuration . 13
6.4 Configuration changes in a device . 13
6.5 Error behaviour: DTM refuses new BMCP . 14
7 Protocol specific usage of general data types . 15
8 Network management data types . 15
8.1 General . 15
8.2 PROFIBUS device address . 15
8.3 Master-bus parameter set . 15
8.4 Slave bus parameter set . 15
8.5 Module and channel data . 15
9 Communication data types. 17
9.1 General . 17
9.2 DPV0 communication – FDTProfibusDPV0CommunicationSchema . 18
9.3 DPV1 communication – FDTProfibusDPV1CommunicationSchema . 19
10 Channel parameter data types . 22
11 Device identification . 23
11.1 Device type identification data types – FDTProfibusIdentSchema . 23
11.2 Topology scan data types – DTMProfibusDeviceSchema . 24
11.3 Scan identification data types – FDTProfibusScanIdentSchema . 25
11.4 Device type identification data types – FDTProfibusDeviceIdentSchema . 27
11.5 XSLT Transformation . 29
Annex A (informative) Example documents for a DTM representing a remote I/O . 40
Bibliography . 43

Figure 1 – Part 51-31 of the IEC 62453 series . 6
Figure 2 – Device DTM . 9
Figure 3 – Gateway DTM . 10
Figure 4 – Composite Device DTM . 11

IEC TR 62453-51-31:2017 © IEC 2017 – 3 –
Figure 5 – Modular Gateway DTM . 12
Figure 6 – Interfaces and information related to bus master configuration . 13
Figure 7 – Changes by the user to the configuration of a device in the DTM user
interface . 14
Figure 8 – Error case – DTM refuses the new BMCP from the Frame Application . 14

Table 1 – Protocol specific usage of general data types . 15

– 4 – IEC TR 62453-51-31:2017 © IEC 2017
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
FIELD DEVICE TOOL (FDT) INTERFACE SPECIFICATION –

Part 51-31: Communication implementation for common object model –
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) 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.
The main task of IEC technical committees is to prepare International Standards. However, a
technical committee may propose the publication of a technical report when it has collected
data of a different kind from that which is normally published as an International Standard, for
example "state of the art".
IEC TR 62453-51-31, which is a echnical report, has been prepared by subcommittee 65E:
Devices and integration in enterprise systems, of IEC technical committee 65: Industrial-
process management, control and automation.
This document cancels and replaces IEC TR 62453-503-1 published in 2009. This edition
constitutes a technical revision. The main changes consist of updates in accordance with
IEC 62453-2 in regard to the description of “Composite Device DTM”.

IEC TR 62453-51-31:2017 © IEC 2017 – 5 –
Each part of the IEC 62453-51-xy series is intended to be read in conjunction with its
corresponding part in the IEC 62453-3xy series. This document corresponds to
IEC 62453-303-1.
The text of this technical report is based on the following documents:
Enquiry draft Report on voting
65E/440/DTR 65E/514/RVC
Full information on the voting for the approval of this technical report can be found in the
report on voting indicated in the above table.
This document has been drafted in accordance with the ISO/IEC Directives, Part 2.
The list of all parts of the IEC 62453 series, 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 "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.
A bilingual version of this publication may be issued at a later date.

IMPORTANT – The 'colour inside' logo on the cover page of this publication 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 TR 62453-51-31:2017 © IEC 2017
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 IEC 62453-51-xy series is aligned in the structure of the
IEC 62453 series.
Part 51-31
Communication
implementation
for common
object model –
IEC 61784 CP 3/1
and CP 3/2
IEC
Figure 1 – Part 51-31 of the IEC 62453 series

IEC TR 62453-51-31:2017 © IEC 2017 – 7 –
FIELD DEVICE TOOL (FDT) INTERFACE SPECIFICATION –

Part 51-31: Communication implementation for common object model –
IEC 61784 CP 3/1 and CP 3/2
1 Scope
This part of the IEC 62435-51-xy series, which is a Technical Report, provides information for
integrating the PROFIBUS protocol into the COM-based implementation of FDT interface
specification (IEC TR 62453-41).
This part of IEC 62453 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-1:2014, Industrial communication networks – Profiles – Part 1: Fieldbus profiles
IEC 62453-1:2016, Field device tool (FDT) interface specification – Part 1: Overview and
guidance
IEC 62453-2:2016, Field device tool (FDT) interface specification – Part 2: Concepts and
detailed description
IEC TR 62453-41:2016, Field device tool (FDT) interface specification – Part 41: Object model
integration profile – Common object model
IEC 62453-303-1:2009, Field device tool (FDT) interface specification – Part 303-1:
Communication profile integration – IEC 61784 CP 3/1 and CP 3/2
IEC 62453-303-1:2009/AMD1:2016
3 Terms, definitions, symbols, 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 TR 62453-41 and IEC 62453-303-1 apply.
___________
1 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 profile does not require use of the
registered logos for PROFIBUS™. Use of the registered logos for PROFIBUS™ requires permission of PNO.

– 8 – IEC TR 62453-51-31:2017 © IEC 2017
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.2 Symbols and abbreviated terms
For the purposes of this document, the symbols and abbreviations given in IEC 62453-1,
IEC 62453-2, IEC 62453-303-1, and IEC TR 62453-41 apply.
3.3 Conventions
3.3.1 Data type names and references to data types
The conventions for naming and referencing of data types are explained in IEC 62453-2:2016,
Clause A.1.
3.3.2 Vocabulary for requirements
The following expressions are used when specifying requirements.
Usage of “shall” or “mandatory” No exceptions allowed.
Usage of “should” or “recommended” Strong recommendation. It may make sense in
special exceptional cases to differ from the
described behaviour.
Usage of “can” or “optional” Function or behaviour may be provided,
depending on defined conditions.
4 Bus category
IEC 61784 CP 3/1 and CP3/2 protocols are identified in the attribute busCategory of
BusCategory element by the identifiers, as specified in IEC 62453-303-1.
IEC 61784 CPF 3 protocols are using the identifiers in physicalLayer members within
PhysicalLayer data type as specified in IEC 62453-303-1.
5 Access to instance and device data
Used at methods:
• IDtmParameter methods
• IDtmSingleDeviceDataAccess methods
• IDtmSingleInstanceDataAccess methods
These methods (if supported according to IEC TR 62453-41) shall provide access to at least
all parameters defined in IEC 62453-303-1.
6 Protocol specific behaviour
6.1 General
A DTM shall deliver its GSD information via method IDtmInformation::GetInformation() and
IDtmParameter::GetParameters(). GSD information is provided in the attribute

IEC TR 62453-51-31:2017 © IEC 2017 – 9 –
. Also, it is required to provide a GSD file for each supported device
type on the hard drive. The attribute in the DTMParameter
document specifies the location of the GSD file.
It is expected that a Profibus DTM in the attribute ‘deviceTypeInformation’ is exposing exactly
the GSD file which is referenced by the attribute ‘deviceTypeInformationPath’.
If the GSD depends on bus settings, a DTM’s configuration or parameterization dialog could
be used to change bus settings. Based on these settings, updated GSD information can be
inserted in the information document. Here too the DTM shall call
IFdtContainer::SaveRequest() and IDtmEvents::OnParameterChanged().
Notice that the internal device structure () with its modules and channels
shall be updated as well.
An example for documents of a DTM representing a remote I/O can be found in Annex A.
6.2 Representing modularity
6.2.1 Monolithic DTMs
Monolithic DTM’s should always provide at least one element.
A monolithic DTM that represents a modular device shall provide the structure information as
part of the element. An element shall be defined for
each element. The IO values of the device are represented by Process Channels,
which are referenced by child elements of the elements. If any of the modules
provides communication, the respective element shall reference a Communication
Channel.
EXAMPLE 1:
A monolithic DTM for a PROFIBUS PA device will provide the information about instantiated modules in the
element. – Each instantiated module will be represented as a element.
The IO values of the modules are represented as Process Channels, which are referenced by child elements of the
elements (see Figure 2).
DTM
Process
Channel
IEC
Figure 2 – Device DTM
The DTM shall provide an internal topology in the parameter document to inform the frame
about the internal structure of the device. The internal topology shall also include the module
structure (element ).
The DTM shall provide all channels in the channel collection based on the current
configuration.
When the DTM changes the configuration of the process data or the module configuration, the
Process Channels shall be updated. This means Process Channels shall be removed/added

– 10 – IEC TR 62453-51-31:2017 © IEC 2017
and the parameter document shall be updated (e.g. by adding/removing elements)
if necessary.
Each channel is represented by a channel reference that is child of a element in the
parameter document.
Each channel object delivers a document based on the
FDTProfibusChannelParameterSchema in IFdtChannel::GetChannelParameters() for the
supported protocol.
EXAMPLE 2:
A monolithic Gateway DTM for a remote I/O system, which requires PROFIBUS communication and has some
modules, which provide HART communication will provide Communication Channels for HART modules that are
also Process Channels and “pure” Process Channels for non-HART modules (see Figure 3).
DTM
Combined
Process
Process
and
Channel
Communication
Channel
IEC
Figure 3 – Gateway DTM
The DTM shall provide all channels in the channel collection based on the current
configuration.
When the DTM changes the configuration of the process data or the module configuration, the
Process Channels shall be updated. This means Process Channels shall be removed/added
and the parameter document shall be updated if necessary.
Communication Channel objects shall implement the interface IFdtCommunication.
Each channel is represented by a channel reference in the parameter document.
The DTM provides an internal topology in the parameter document to inform the frame about
the internal structure of the device.
Each channel object delivers a document based on the
FDTProfibusChannelParameterSchema in IFdtChannel::GetChannelParameters() for the
supported protocol.
6.2.2 Composite Device DTMs
If a DTM is designed as a Composite Device DTM, the BIM DTM provides Communication
Channels for connecting the Module DTMs. These channels are not Process Channels.
EXAMPLE 1:
A modular device will be represented by a Composite Device DTM to represent the head station and a number of
Module DTMs to represent the modules. The Module DTMs for the modules will provide Process Channels (see
Figure 4).
IEC TR 62453-51-31:2017 © IEC 2017 – 11 –
DTM (represents the BIM)
„marshalled“
Communication
Process
Channel
Channel
Module DTM
represents
Process
Channel
IEC
Figure 4 – Composite Device DTM
Since the BIM DTM represents the PROFIBUS slave device from the communication point of
view, it has to deliver the Process Channels of the complete device. This has the following
consequences:
The BIM DTM shall provide the channel objects in the channel collection that represent its
Communication Channels. These channel objects implement the interfaces
IFdtCommunication.
The BIM DTM shall provide channel objects in the channel collection representing the
Process Channels of the modules. The Process Channels are called “marshalled channel”.
These channel objects do not implement the interfaces IFdtCommunication.
The BIM DTM does not provide an internal topology because the project itself with the
BIM DTM and the Module DTMs represent the device structure.
The BIM DTM shall provide a channel reference in its parameter document for ALL the
channels in the channel collection based on the current configuration.
Each Communication Channel of the BIM DTM delivers a document based on the
BasicChannelParameterSchema when it receives IFdtChannel::GetChannelParameters() for
any of its supported protocols.
Each marshalled channel of the BIM DTM delivers a document based on the
FDTProfibusChannelParameterSchema when it receives
IFdtChannel::GetChannelParameters() for any of its supported protocols.
A Module DTM shall deliver a channel reference in its parameter document for each channel.
Each channel of a Module DTM delivers a document based on the
FDTProfibusChannelParameterSchema in IFdtChannel::GetChannelParameters() for the
supported protocol.
– 12 – IEC TR 62453-51-31:2017 © IEC 2017
Every time when a module changes the configuration so that the Process Channels
(configuration or amount of Process Channels) changes, the BIM shall update the Process
Channels and the parameter document.
When a module is added or removed from the BIM, the BIM shall add/remove the Process
Channels of this module and update the parameter document.
EXAMPLE 2:
When a modular I/O system as described by EXAMPLE 1 of 6.2.2 also has some modules which provide HART
communication, it will be represented by a Composite Device DTM to represent the head station and a number of
Module DTMs to represent the modules. The Module DTMs for the communication modules will provide
Communication Channels. These channels represent also Process Channels.
Modules that are not used for communication will provide Process Channels only (see Figure 5).
DTM (represents the BIM)
„marshalled“
Communication
Process
Channel
Channel
Module DTM
Module DTM
with HART
without communication
communication
represents
Communication Process
Channel Channel
IEC
Figure 5 – Modular Gateway DTM
Since the BIM represents the PROFIBUS slave device from the communication point of view,
it shall deliver the Process Channels of the complete device. This has the following
consequences:
The BIM DTM shall provide the channel objects in the channel collection that represent its
Communication Channels. These channel objects implement the interfaces
IFdtCommunication.
The BIM DTM shall provide channel objects in the channel collection representing the
Process Channels of the modules. The Process Channels are called “marshalled channel”.
These channel objects do not implement the interfaces IFdtCommunication.
The BIM shall deliver a channel reference in its parameter document for all the channels in
the channel collection based on the current configuration.
The BIM does not provide an internal topology because the project itself with the BIM and the
Module DTMs represent the device structure.

IEC TR 62453-51-31:2017 © IEC 2017 – 13 –
The BIM DTM shall provide a channel reference in its parameter document for all the
channels in the channel collection based on the current configuration.
Each Communication Channel of the BIM DTM delivers a document based on the
BasicChannelParameterSchema when it receives IFdtChannel::GetChannelParameters() for
any of its supported protocols.
Each marshalled channel of the BIM DTM delivers a document based on the
FDTProfibusChannelParameterSchema when it receives
IFdtChannel::GetChannelParameters() for any of its supported protocols.
A Module DTM shall provide a channel reference in its parameter document for each channel
(if applicable).
Each channel of a Module DTM delivers a document based on the Basic Channel Schema
when it receives IFdtChannel::GetChannelParameters() for any of its supported or required
protocols.
Every time a module changes the configuration so that the Process Channels (configuration
or amount of Process Channels) changes, the BIM shall update the Process Channels and the
parameter document.
When a module is added or removed from the BIM, the BIM shall add/remove the process
channels of this module and update the parameter document.
6.3 Interfaces and information related to Bus Master Configuration
Figure 6 shows the interfaces and methods related to establishing DPV0 functionality in DCS
environments. The interface IFdtTopology is required only for a Composite Device DTM.
IEC
Figure 6 – Interfaces and information related to bus master configuration
NOTE The BMCP contains (besides other parts) two important parts called Prm_Data and Cfg_Data. Often these
two parts are called Parameter-String and Config-String.
6.4 Configuration changes in a device
The sequence related to configuration changes is shown in Figure 7.

– 14 – IEC TR 62453-51-31:2017 © IEC 2017
Frame DTM FdtChannel(s) Presentation
Application Object "Configuration"
Note: Display the
Frame starts the FDT
current modules
Standard user interface
with the help of DTM.
"Configuration" of the DTM.
Details in IEC TR 62453-41: Channels which are
ProtectedByChannel-
2016, 7.13.3
Assignment shall be
disabled!
User changes the
Note: DTM internal, can configuration of the
be solved in different ways
devices modules.
DTM changes the BMCP, Pressing e.g. an
destroys unused channels,
"apply" Button will safe
Sending changes to the DTM
creates new channels.
the new settings
Adjust the channel objects
IFdtContainer::SaveRequest
IPersistPropertyBag::Save(…)
Note: Important to keep
this sequence, otherwise
IDtmEvents::OnParamChanged the frame is not informed
User Interface is closed
about changes and will not
somewhere in time by
start the following actions
Get structure information
the user
IDtmParameter::GetParameters
of the device and channel
References.
IDtmChannel::GetChannels
Get all channels or a
single channel via
Channels tell their
reference IFdtChannel::GetChannelParameters
configuration and settings
FOR all instance specific
according to the FDTProfibus-
channels DO
ChannelParameterSchema.xml
END
IEC
Figure 7 – Changes by the user to the configuration
of a device in the DTM user interface
6.5 Error behaviour: DTM refuses new BMCP
A DTM is expected to check the BMCP and may refuse an incorrect BMCP (see Figure 8).
Frame
DTM
Application
DTM enters default BMCP,
IDtmParameter::GetParameters
Get structure information
the internal topology including
of the device and channel
module description and channel
references.
references in the appropriate
XML attributes
FOR all slaves DO
The frame reads the
network specific configu-
ration parts of devices.
IDtmParameter::SetParameters
Write the network specific
DTM checks the BMCP. The BMCP
configuration parts of the
has critical errors (e.g. wrong length)
master device.
A DTM shall accept a valid BMCP.
END
If a DTM refuses a BMCP without strong
reason (e.g. wrong structure) this can result
Return: FALSE
in critical problems with the bus configuration
by the master.
IEC
Figure 8 – Error case – DTM refuses the new BMCP
from the Frame Application
IEC TR 62453-51-31:2017 © IEC 2017 – 15 –
7 Protocol specific usage of general data types
Table 1 shows how general data types are used with IEC 61784 CP 3/1 and CP 3/2 devices.
Table 1 – Protocol specific usage of general data types
Attribute Description for use
fdt:address All these attributes of the FDTDatatype schema are used as defined
in IEC 62453-303-1.
fdt:protocolId
fdt:deviceTypeId
fdt:deviceTypeInformation
fdt:deviceTypeInformationPath
fdt:manufacturerId
fdt:semanticId
fdt:applicationDomain
fdt:tag
8 Network management data types
8.1 General
The data types specified in this clause are used at the following methods:
• IDtmParameter:GetParameters
• IDtmParameter:SetParameters
8.2 PROFIBUS device address
The address of a PROFIBUS device is available at the attribute
.
8.3 Master-bus parameter set
The parameter set represents the content of the attribute busMasterConfigurationPart within
the DTMParameterSchema for Profibus master device. This attribute shall be set for each
Profibus master device according to the IEC 61158 series. For further details, refer to 6.3 of
IEC 62453-2:2016, Clause 9 of IEC 62453-303-1:2009/AMD1:2016 and the IEC 61158 series.
8.4 Slave bus parameter set
The parameter set represents the content of the attribute busMasterConfigurationPart within
the DTMParameterSchema for Profibus slave devices. This attribute shall be set for each
Profibus slave device according to the IEC 61158 series. For further details, refer to 6.3 of
IEC 62453-2:2016, Clause 9 of IEC 62453-303-1:2009/AMD1:2016 and the IEC 61158 series.
8.5 Module and channel data
Corresponding XML documents:
• DTM Parameters:

fdt:storageState="persistant" fdt:dataSetState="default">



– 16 – IEC TR 62453-51-31:2017 © IEC 2017











descriptor="Digital Input (Counter 4 Byte"/>







descriptor="Valve Block LB/FB 2XXX 1Byte Input Output"/>













• FDT-Channel “Count_1_0”:



date="2000-08-05"/>

fdt:dataType="int" fdt:signalType="input">



• FDT-Channel “DI_8_LFOUT0”:



date="2000-08-05"/>

fdt:dataType="binary" fdt:signalType="input">



• FDT-Channel “DI_8_1”:



date="2000-08-05"/>

fdt:dataType="binary" fdt:signalType="input">

IEC TR 62453-51-31:2017 © IEC 2017 – 17 –




• FDT-Channel “DI_8_LF1”:



date="2000-08-05"/>

fdt:dataType="binary" fdt:signalType="input">



• FDT-Channel “DI_8_2”:



date="2000-08-05"/>

fdt:dataType="binary" fdt:signalType="input">




• FDT-Channel “DI_8_LF2”:



date="2000-08-05"/>

fdt:dataType="binary" fdt:signalType="input">



• FDT-Channel “DO_8_0”:



date="2000-08-05"/>

...