CLC/TR 62453-503-1:2009

SLOVENSKI STANDARD
01-februar-2010
Specifikacija vmesnika orodja procesne naprave - 503-1. del: Implementacija
komunikacije za skupni model objekta - IEC 61784 CP 3/1 in CP 3/2 (IEC/TR 62453-
503-1:2009)
Field device tool interface specification -- Part 503-1: Communication implementation for
common object model - IEC 61784 CP 3/1 and CP 3/2
Field Device Tool (FDT)-Schnittstellenspezifikation - Teil 503-1:
Kommunikationsimplementierung mit dem allgemeinen Objektmodell (COM) - IEC 61784
Kommunikationsprofile (CP) 3/1 und 3/2
Ta slovenski standard je istoveten z: CLC/TR 62453-503-1:2009
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-503-1
RAPPORT TECHNIQUE
November 2009
TECHNISCHER BERICHT
ICS 25.040.40; 35.100.05; 35.110

English version
Field device tool (FDT) interface specification -
Part 503-1: Communication implementation for common object model -
IEC 61784 CP 3/1 and CP 3/2
(IEC/TR 62453-503-1:2009)
Spécification des interfaces des  Field Device Tool (FDT)-
outils des dispositifs de terrain (FDT) - Schnittstellenspezifikation -
Partie 503-1: Implémentation Teil 503-1: Kommunikationsimplementierung
des communications mit dem allgemeinen Objektmodell (COM) -
pour le modèle objet commun - Kommunikationsprofile (CP) 3/1 und 3/2
CEI 61784 CP 3/1 et CP 3/2 nach IEC 61784
(CEI/TR 62453-503-1:2009) (IEC/TR 62453-503-1:2009)

This Technical Report was approved by CENELEC on 2009-10-01.

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

CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung

Central Secretariat: Avenue Marnix 17, B - 1000 Brussels

© 2009 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. CLC/TR 62453-503-1:2009 E

Foreword
The text of document 65E/67/CDV, future edition 1 of IEC/TR 62453-503-1, prepared by SC 65E, Devices
and integration in enterprise systems, of IEC TC 65, Industrial-process measurement, control and
automation, was submitted to the IEC-CENELEC parallel vote and was approved by CENELEC as
CLC/TR 62453-503-1 on 2009-10-01.
This standard is to be used in conjunction with EN 62453-3xy series.
Annex ZA has been added by CENELEC.
__________
Endorsement notice
The text of the Technical Report IEC/TR 62453-503-1:2009 was approved by CENELEC as a Technical
Report without any modification.
In the official version, for Bibliography, the following note has to be added for the standard indicated:
IEC 61784-1 NOTE  Harmonized as EN 61784-1:2008 (not modified).
__________
- 3 - CLC/TR 62453-503-1:2009
Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications

The following referenced documents are indispensable for the application 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  When an international publication has been modified by common modifications, indicated by (mod), the relevant EN/HD
applies.
Publication Year Title EN/HD Year

IEC 61158 series Industrial communication networks - Fieldbus EN 61158 series
specifications
IEC 62453-1 2009 Field device tool (FDT) interface EN 62453-1 2009
specification -
Part 1: Overview and guidance
IEC 62453-2 2009 Field device tool (FDT) interface EN 62453-2 2009
specification -
Part 2: Concepts and detailed description

IEC/TR 62453-41 2009 Field device tool (FDT) interface CLC/TR 62453-41 2009
specification -
Part 41: Object model integration profile -
Common object model
IEC 62453-303-1 2009 Field device tool (FDT) interface EN 62453-303-1 2009
specification -
Part 303-1: Communication profile
integration - IEC 61784 CP 3/1 and CP 3/2

__________
IEC/TR 62453-503-1 ®
Edition 1.0 2009-08
TECHNICAL
REPORT
colour
inside
Field device tool (FDT) interface specification –
Part 503-1: Communication implementation for common object model –
IEC 61784 CP 3/1 and CP 3/2
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
X
ICS 25.040.40; 35.100.05; 35.110 ISBN 2-8318-1058-3
– 2 – TR 62453-503-1 © IEC:2009(E)
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.7
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 behavior.8
6.1 General .8
6.2 Representing modularity.9
6.2.1 Monolithic DTMs.9
6.2.2 Modular DTMs .10
6.3 Interfaces and Information related to Bus Master Configuration.13
6.4 Configuration changes in a device.13
6.5 Error behavior: DTM refuses new BMCP .14
7 Protocol specific usage of general data types .14
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 .18
9.1 General .18
9.2 DPV0 communication – FDTProfibusDPV0CommunicationSchema .18
9.3 DPV1 communication – FDTProfibusDPV1CommunicationSchema .20
10 Channel parameter data types.23
11 Device identification .25
11.1 Device type identification data types – FDTProfibusIdentSchema.25
11.2 Topology scan data types – DTMProfibusDeviceSchema.26
11.3 Scan identification data types – FDTProfibusScanIdentSchema .26
11.4 Device type identification data types – FDTProfibusDeviceIdentSchema .29
11.5 XSLT Transformation .30
Annex A (informative) Example documents for a DTM representing a Remote I/O.43
Bibliography.46

Figure 1 – Part 503-1 of the IEC 62453 series .6
Figure 2 – Example: Device DTM.9
Figure 3 – Example: Gateway DTM.10
Figure 4 – Example: Modular DTM.11

TR 62453-503-1 © IEC:2009(E) – 3 –
Figure 5 – Example: Modular Gateway DTM .12
Figure 6 – Interfaces and information related to bus master configuration.13
Figure 7 – User changes the configuration of a device in the DTMs user interface .14
Figure 8 – Error case: DTM refuses the new BMCP from the frame.14

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

– 4 – TR 62453-503-1 © IEC:2009(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
FIELD DEVICE TOOL (FDT) INTERFACE SPECIFICATION –

Part 503-1: 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 provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
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-503-1, which is a technical report, has been prepared by subcommittee 65E:
Devices and integration in enterprise systems, of IEC technical committee 65: Industrial-
process measurement, control and automation:
This part, in conjunction with the other parts of the first edition of the IEC 62453 series
cancels and replaces IEC/PAS 62453-1, IEC/PAS 62453-2, IEC/PAS 62453-3, IEC/PAS
62453-4 and IEC/PAS 62453-5 published in 2006, and constitutes a technical revision.
Each part of the IEC/TR 62453-5xy series is intended to be read in conjunction with its
corresponding part in the IEC 62453-3xy series.

TR 62453-503-1 © IEC:2009(E) – 5 –
The text of this technical report is based on the following documents:
Enquiry draft Report on voting
65E/67/DTR 65E/116/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 publication 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 publication will remain unchanged until
the maintenance result date indicated on the IEC web site under "http://webstore.iec.ch" in
the data related to the specific publication. At this date, the publication 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 publication using a colour printer.

– 6 – TR 62453-503-1 © IEC:2009(E)
INTRODUCTION
This part of IEC 62453 is an interface specification for developers of FDT (Field Device Tool)
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 fieldbusses 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 DTM (Device Type Manager), 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 fieldbusses and thus meets the requirements for integrating different kinds of
devices into heterogeneous control systems.
Figure 1 shows how IEC/TR 62453-503-1 is aligned in the structure of IEC 62453 series.
Part 503-1
Communication
implementation
for common
object model –
IEC 61784 CP 3/1
and CP 3/2
Figure 1 – Part 503-1 of the IEC 62453 series

TR 62453-503-1 © IEC:2009(E) – 7 –
FIELD DEVICE TOOL (FDT) INTERFACE SPECIFICATION –

Part 503-1: Communication implementation for common object model –
IEC 61784 CP 3/1 and CP 3/2
1 Scope
IEC 62435-503-1, which is a technical report, provides information for integrating the
PROFIBUS protocol into the FDT interface specification (IEC 62453-2).
This part of IEC 62453 specifies communication and other services.
This specification neither contains the FDT specification nor modifies it.
2 Normative references
The following referenced documents are indispensable for the application of this specification.
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 62453-1:2009, Field Device Tool (FDT) interface specification – Part 1: Overview and
guidance
IEC 62453-2:2009, Field Device Tool (FDT) interface specification – Part 2: Concepts and
detailed description
IEC/TR 62453-41:2009 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
3 Terms, definitions, symbols, abbreviated terms and conventions
3.1 Terms and definitions
For the purpose of this document, the terms and definitions given in IEC 62453-1 and
IEC 62453-2 apply.
3.2 Symbols and abbreviated terms
For the purpose of this document, the symbols and abbreviations given in IEC 62453-1,
IEC 62453-2 and the following apply.
UML Unified Modelling Language [ISO/IEC 19501]

– 8 – TR 62453-503-1 © IEC:2009(E)
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
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 behavior.
Usage of “can’ or “Optional’ Function or behavior 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::GetParameters()
• IDtmParameter::SetParameters()
These methods shall provide access to at least to all parameters defined in IEC 62453-303-1.
6 Protocol specific behavior
6.1 General
A DTM shall deliver its GSD information via method IDtmInformation::GetInformation() and
IDtmParameter::GetParameters(). GSD information is provided in the attribute
. 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 has to call
IFdtContainer::SaveRequest() and IDtmEvents::OnParameterChanged().

TR 62453-503-1 © IEC:2009(E) – 9 –
Notice that the internal device structure () with its modules and channels
has to 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. 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. (Be aware: it
is necessary to define an element for each 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
Figure 2 – Example: Device DTM
This means:
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
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

– 10 – TR 62453-503-1 © IEC:2009(E)
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
Figure 3 – Example: Gateway DTM
This means:
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 implements 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 Modular DTMs
If a DTM is designed in a modular way, 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 Gateway 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)

TR 62453-503-1 © IEC:2009(E) – 11 –
DTM (represents the BIM)
„marshalled“
Communication
Process
Channel
Channel
Module DTM
represents
Process
Channel
Figure 4 – Example: Modular 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 does not provide an internal topology because the project itself with the BIM 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 has to 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 – TR 62453-503-1 © IEC:2009(E)
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 has to 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 also has some modules which provide HART
communication, it will be represented by a Gateway 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
Figure 5 – Example: Modular Gateway DTM
Since the BIM 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 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.
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

TR 62453-503-1 © IEC:2009(E) – 13 –
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 has to 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 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 has to add/remove the process
channels of this module and update the parameter document.
6.3 Interfaces and Information related to Bus Master Configuration
The following graphic (Figure 6) shows the interfaces and methods related to establishing
DPV0 functionality in DCS environments. The interface IFdtTopology is required only for a
modular DTM.
IDIDttmmAAccttiiveXveXCCoonnttrrooll
DDTTMM FFrarameme ap appplicalicattioionn
(C(Coonfnfiigugurraatitionon ddiiaalloogg avavailailablablee vviia a
FDFDT ST Stantandard dard FuFunctinctionon ""CCoonnffiigugurree""))
lloadoadeded frofromm
ininssttalallalattiionon ffoollddeerr
IniInitt
PPrrepaeparreeTToRoReleleaeassee
IIFdtFdtCContontaaineinerr
IDtmIDtm
SSaavveeRRequequestest
GGetIetInnfforormmaatitionon
InteInterrnnalal
GSGSDD
TTopoopolologgyy IIDDtmtmEEvveenntsts
FileFiless
OOnPnPaarramameettererCChahanngedged
IIDDtmtmPPaararammeeteterr
SSeettPParamarameeteterrss
BMBMCCPP
GGeetPtParaarammetetersers
IFdtToIFdtTopolpologogyy
MoModuldules:es:
GGeetCtChihildldNNoodesdes
IFdtChaIFdtChannennell
CChanhannelnelCCoollellectictioonn
GGetCetChahannennelPlParaarammeteeterrss
CChanhannelnel 11
SSetCetChahannennelPlPaarraammeteeterrss
......
GGetCetChahannennelPlPathath
......
CChanhannelnel nn
IIDDtmChannetmChannell
GGetCetChahannennelsls
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 – TR 62453-503-1 © IEC:2009(E)
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 sequence chart
Channels which are
[1], 5.12.3
ProtectedByChannel-
Assignment must be
disabled according
to styleguide!
User changes the
configuration of the
Note: DTM internal, can
devices modules.
be solved in different ways
Pressing e.g. an „Apply“
DTM changes the BMCP,
Button will safe the new
destroys unused channels,
Sending changes to the DTM settings
creates new channels.
Adjust the channel objects
IFdtContainer::SaveRequest
IPersistPropertyBag::Save(…)
Note: Important to keep
this sequence, otherwise
IDtmEvents::OnParamChanged the frame is not informed
about changes and will not User Interface is closed
somewhere in time by
start the following actions
the user
Get structure information
IDtmParameter::GetParameters
of the device and channel
References.
IDtmChannel::GetChannels
Get all channels or a
single channel via
reference
IFdtChannel::GetChannelParameters Channels tell their
FOR all instance specific
configuration and settings
channels DO
according to the FDTProfibus-
END
ChannelParameterSchema.xml
Figure 7 – User changes the configuration of a device in the DTMs user interface
6.5 Error behavior: DTM refuses new BMCP
A DTM is expected to check the BMPC and may refuse an incorrect BMCP (see Figure 8).
Frame DTM
Application
IDtmParameter::GetParameters
DTM enters default BMCP,
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
DTM checks the BMCP. The BMCP
Write the network specific
has critical errors (e.g. wrong length)
configuration part of the
master device.
Note: A DTM has to 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.
Figure 8 – Error case: DTM refuses the new BMCP from the frame
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.

TR 62453-503-1 © IEC:2009(E) – 15 –
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 following methods:
• IDtmParameter:GetParameters
• IDtmParameter:SetParameters
All parameters defined in EDS in ther [Params]-sectioon shall be exposed by these methods.
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 has to be set for each
Profibus master device according to the IEC 61158 series. For further details please refer to
the sequence chart “Configuration of a Fieldbus Master” (IEC 62453-2), IEC 62453-303-1 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 has to be set for each
Profibus slave device according to the IEC 61158 series. For further details please refer to
the sequence chart “Configuration of a Fieldbus Master” (IEC 62453-2), IEC 62453-303-1 and
the IEC 61158 series.
8.5 Module and channel data
Corresponding XML documents:
• DTM Parameters:

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



– 16 – TR 62453-503-1 © IEC:2009(E)











08”05" descriptor"Digital Input (Counter 4 Byte"/>





















• FDT-Channel “Count_1_0”:



date="2000-08”05"/>

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



• FDT-Channel “DI_8_LFOUT0”:



date="2000-08-05"/>

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



TR 62453-503-1 © IEC:2009(E) – 17 –
• FDT-Channel “DI_8_1”:



date="2000-08-05"/>

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




• 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”:

– 18 – TR 62453-503-1 © IEC:2009(E)


date="2000-08-05"/>

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




9 Communication data types
9.1 General
The data types specified in this clause are used with the methods of IFdtCommunication.
9.2 DPV0 communication – FDTProfibusDPV0CommunicationSchema
The XML document contains the address information and the communication data needed for
DP communication. The definition of the attributes and elements follows the data type
definition as defined in IEC 62453-303-1.
xmlns:dt="urn:schemas-microsoft-com:datatypes" xmlns:fdt="x-schema:FDTDataTypesSchema.xml">