IEC TR 62453-503-1:2009

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


IEC/TR 62453-503-1:2009(E)

---------------------- Page: 1 ----------------------
THIS PUBLICATION IS COPYRIGHT PROTECTED
Copyright © 2009 IEC, Geneva, Switzerland

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.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite
ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie
et les microfilms, sans l'accord écrit de la CEI ou du Comité national de la CEI du pays du demandeur.
Si vous avez des questions sur le copyright de la CEI ou si vous désirez obtenir des droits supplémentaires sur cette
publication, utilisez les coordonnées ci-après ou contactez le Comité national de la CEI de votre pays de résidence.

IEC Central Office
3, rue de Varembé
CH-1211 Geneva 20
Switzerland
Email: inmail@iec.ch
Web: www.iec.ch

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 corrigenda or an amendment might have been published.
ƒ Catalogue of IEC publications: www.iec.ch/searchpub
The IEC on-line Catalogue enables you to search by a variety of criteria (reference number, text, technical committee,…).
It also gives information on projects, withdrawn and replaced publications.
ƒ IEC Just Published: www.iec.ch/online_news/justpub
Stay up to date on all new IEC publications. Just Published details twice a month all new publications released. Available
on-line and also by email.
ƒ Electropedia: www.electropedia.org
The world's leading online dictionary of electronic and electrical terms containing more than 20 000 terms and definitions
in English and French, with equivalent terms in additional languages. Also known as the International Electrotechnical
Vocabulary online.
ƒ Customer Service Centre: www.iec.ch/webstore/custserv
If you wish to give us your feedback on this publication or need further assistance, please visit the Customer Service
Centre FAQ or contact us:
Email: csc@iec.ch
Tel.: +41 22 919 02 11
Fax: +41 22 919 03 00

---------------------- Page: 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 978-2-88910-728-5
® Registered trademark of the International Electrotechnical Commission

---------------------- Page: 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

---------------------- Page: 4 ----------------------
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

---------------------- Page: 5 ----------------------
– 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.

---------------------- Page: 6 ----------------------
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.

---------------------- Page: 7 ----------------------
– 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

---------------------- Page: 8 ----------------------
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]

---------------------- Page: 9 ----------------------
– 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().

---------------------- Page: 10 ----------------------
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

---------------------- Page: 11 ----------------------
– 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)

---------------------- Page: 12 ----------------------
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.

---------------------- Page: 13 ----------------------
– 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

---------------------- Page: 14 ----------------------
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
...