IEC PAS 62453-3:2006

PUBLICLY
IEC
AVAILABLE
PAS 62453-3
SPECIFICATION
First edition
Pre-Standard
2006-05
Field Device Tool (FDT) interface specification –

Part 3:
PROFIBUS communication
Reference number
IEC/PAS 62453-3:2006(E)
Publication numbering
As from 1 January 1997 all IEC publications are issued with a designation in the
60000 series. For example, IEC 34-1 is now referred to as IEC 60034-1.

Consolidated editions
The IEC is now publishing consolidated versions of its publications. For example,
edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the base publication, the
base publication incorporating amendment 1 and the base publication incorporating
amendments 1 and 2.
Further information on IEC publications
The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology. Information relating to
this publication, including its validity, is available in the IEC Catalogue of
publications (see below) in addition to new editions, amendments and corrigenda.
Information on the subjects under consideration and work in progress undertaken
by the technical committee which has prepared this publication, as well as the list
of publications issued, is also available from the following:
• IEC Web Site (www.iec.ch)
• Catalogue of IEC publications
The on-line catalogue on the IEC web site (www.iec.ch/searchpub) enables you to
search by a variety of criteria including text searches, technical committees
and date of publication. On-line information is also available on recently issued
publications, withdrawn and replaced publications, as well as corrigenda.
• IEC Just Published
This summary of recently issued publications (www.iec.ch/online_news/ justpub)
is also available by email. Please contact the Customer Service Centre (see
below) for further information.
• Customer Service Centre
If you have any questions regarding this publication or need further assistance,
please contact the Customer Service Centre:

Email: custserv@iec.ch
Tel: +41 22 919 02 11
Fax: +41 22 919 03 00
PUBLICLY
IEC
AVAILABLE
PAS 62453-3
SPECIFICATION
First edition
Pre-Standard
2006-05
Field Device Tool (FDT) interface specification –

Part 3:
PROFIBUS communication
 IEC 2006  Copyright - all rights reserved
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 the publisher.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch Web: www.iec.ch
PRICE CODE
Commission Electrotechnique Internationale
X
International Electrotechnical Commission
Международная Электротехническая Комиссия
For price, see current catalogue

– 2 – PAS 62453-3  IEC:2006
CONTENTS
FOREWORD.4

INTRODUCTION.6

1 Scope .7

2 Normative references .7

3 General .7

3.1 PROFIBUS schema .7

3.1.1 Configuration .7

3.1.2 Channels .8
3.1.3 Parameterization.8
4 Provided data .8
4.1 Interface IDtmParameter.8
4.2 SingleDataAccess interfaces.9
5 Protocol specific usage of XML attributes.9
6 Bus category .11
7 Communication schema.12
7.1 DPV0 communication.12
7.2 DPV1 communication.18
8 ChannelParameterSchema .21
9 Topology scan schema .25
10 Master-bus parameter set .25
11 Slave bus parameter set .26
12 Module and channel data.27
13 ProfiSafe .31
13.1 Motivation .31
13.2 General parameter handling.31
13.3 ProfiSafe individual device parameter .32
14 GSD information.33
15 Profibus device identification .34
15.1 FDTProfibusIdentSchema .34
15.2 FDTProfibusScanIdentSchema .39
15.3 FDTProfibusDeviceTypeIdentSchema .43

16 General recommendations .45
BIBLIOGRAPHY .46

Figure 1 – Example for IO data within telegramms .27
Figure 2 − F-Parameter and individual device parameter .32
Figure 3 − Data structure of ProfiSafe individual device parameters .33

Table 1 – SingleDataAccessSchema attributes .9
Table 2 − DPV0CommunicationSchema attributes .12
Table 3 − DPV0CommunicationSchema elements.13
Table 4 – Availability of services depending on master and connect status.15
Table 5 − DPV1CommunicationSchema attributes and elements.18
Table 6 – Mapping of DPV1 data types to FDT data types.21

PAS 62453-3  IEC:2006 – 3 –
Table 7 − ChannelParameter attributes and elements .22

Table 8 − Bus parameter set for master device.25

Table 9 − Bus parameter set for slave device .26

Table 10 − Signal channels within the data frame .28

Table 11 − FDTProfibusIdentSchema – attributes with Profibus DP specific mapping .34

Table 12 − FDTProfibusIdentSchema – attributes with Profibus I&M specific mapping .35

Table 13 − FDTProfibusIdentSchema – attributes with Profibus PA specific mapping .37

Table 14 – FDTProfibusIdentSchema – attributes with protocol independent

semantics .38

Table 15 – ProfibusDeviceTypeIdentSchema – attributes and elements .43

– 4 – PAS 62453-3  IEC:2006
INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________
Field Device Tool (FDT) interface specification –

Part 3: PROFIBUS communication

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.

A PAS is a technical specification not fulfilling the requirements for a standard but made
available to the public.
IEC-PAS 62453-3 has been processed by subcommittee 65C: Digital communications, of IEC
technical committee 65: Industrial-process measurement and control.
The text of this PAS is based on the This PAS was approved for
following document: publication by the P-members of the
committee concerned as indicated in
the following document
Draft PAS Report on voting
65C/398A/NP 65C/411/RVN
Following publication of this PAS, which is a pre-standard, the technical committee or
subcommittee concerned will transform it into an International Standard.

PAS 62453-3  IEC:2006 – 5 –
This PAS shall remain valid for an initial maximum period of three years starting from

2006-05. The validity may be extended for a single three-year period, following which it shall

be revised to become another type of normative document or shall be withdrawn.

IEC 62453 consists of the following parts under the general title Field Device Tool (FDT)

interface specification:
Part 1: Concepts and detailed description

Part 2: INTERBUS communication

Part 3: PROFIBUS communication

Part 4: HART communication
Part 5: FOUNDATION FIELDBUS communication

– 6 – PAS 62453-3  IEC:2006
INTRODUCTION
This PAS is an interface specification for developers of 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 shall inter-operate seamlessly.

With the integration of fieldbusses into control systems, there are a few other tasks which

must be performed. This applies to fieldbusses in general. Although there are fieldbus- and

device-specific tools, there is no unified way to integrate those 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.

PAS 62453-3  IEC:2006 – 7 –
Field Device Tool (FDT) interface specification –

Part 3: PROFIBUS communication

1 Scope
This part of IEC 62435 provides information for integrating the PROFIBUS protocol into the

FDT interface specification (IEC 62453-1). This PAS neither contains the FDT specification

nor modifies it.
2 Normative references
The following referenced documents are indispensable for the application of this PAS. For
dated references, only the edition cited applies. For undated references, the latest edition of
the referenced document (including any amendments) applies
IEC 61158:2003 (all parts), Digital data communications for measurement and control –
Fieldbus for use in industrial control systems
IEC 61158-2:2003, Digital data communications for measurement and control – Fieldbus for
use in industrial control systems – Part 2: Physical layer specification and service definition
IEC 61158-5:2003, Digital data communications for measurement and control – Fieldbus for
use in industrial control systems – Part 5: Application layer service definition
IEC 62453-1, Field Device Tool (FDT) interface specification – Part 1: Concepts and detailed
description
3 General
3.1 PROFIBUS schema
PROFIBUS schemas are required to define the structure and semantics of the protocol-
specific data transferred via XML documents on the FDT interfaces.
The schemas are based on definitions given in the PROFIBUS-Specification. Furthermore,
they contain additional information about the device that is needed by systems to configure

PROFIBUS links and to establish communication between the PROFIBUS master device and
the PROFIBUS slave devices.
3.1.1 Configuration
The configuration of the device itself is done with the aid of the DTM’s GUI. Downloading the
configuration into the slave device is performed via the PROFIBUS master device. To do that
and in order to set up the bus communication the master needs information from the DTM as
there is:
• GSD file
The GSD information is type-specific information and not instance-specific. It is not stored
with single slave instances or in a global accessible file. It is provided by the DTm at
IDtmInformation. On method GetInformation(), a DTM of a PROFIBUS device provides the
GSD information within its XML document.
The master device can use the general type-specific information from the slave’s GSD
information like bus timing parameters, supported baud rates etc.

– 8 – PAS 62453-3  IEC:2006
• CFG-String (Cfg_Data)
The CFG-String provides the instance-specific information about the current configuration

of the device. It defines the structure of the data frames that will be transmitted on the

PROFIBUS. This structure depends on the modules that are actually configured.

The DTM provides the CFG-String within the attribute busMasterConfigurationPart that is

part of the XML document available via IDtmParameter::GetParameters(). The structure of

the busMasterConfigurationPart is defined according to the PROFIBUS-DP-Slave-Bus-
Parameter- Set (see Bibliography and also IEC 61158 series).
The master device uses this information to set up communication with the slave device.

3.1.2 Channels
In case of PROFIBUS, an FDT channel is a representative for a single date or a process
value that can be accessed from a Frame Application via the master device. The XML
document available at IFdtChannel describes how to access a channel via a PROFIBUS
DPV1 command or how to address a channel within a PROFIBUS DP frame for cyclic I/O.
Besides all mandatory elements (which includes id and dp address) it is highly recommended
that the XML document provides DPV1 address information. This information (DPV1 Slot) is
used by some frames to manage the PROFIBUS device module information.
In a DPV0 environment, depending on the situation, the underlying master device may have
either Master Class 1 functionality or Master Class 2 functionality. A Class 1 master can write
output data to a device and control data exchange, where a Class 2 master can only read the
output data. Generally it is assumed that parameterization as described here is performed as
a master Class 2 station.
3.1.3 Parameterization
There are two options to write parameters set from the DTM’s GUI to the PROFIBUS slave
device in the field:
• User Parameters
User Parameters are part of the PROFIBUS-DP-Slave-Bus-Parameter-Set. They contain
manufacturer-specific data to characterize the DP-Slave. The DTM writes the User
Parameters to the busMasterConfigurationPart. The User Parameters are stored with the
master device during PROFIBUS master configuration and are automatically sent to the
slave during the setup of bus communication. (This is PROFIBUS-specific; for details, see
IEC 61158 series.) When changing User Parameters on runtime, the DTM must use a DP-
V0 connection and the appropriate DP-V0 commands for parameter exchange as
described in the XML schemas.
• Writing Parameters with DP-V1 services (MSAC2 services)
The DTM may use DP-V1 transport services to send its parameters to the slave device. For
that, it has to use a DP-V1 connection and the corresponding communication commands.

During the setup of communication, DP-V1 services are not sent automatically. The Frame
Application or a DTM must invoke a download of parameters via DP-V1.
For details on the different behavior of slaves depending on the kind of parameterization,
refer to the IEC 61158 series.
DP-V1 connections and communication commands can also be used to execute commands at
the slave. For details on the use of DP-V1, see also IEC 61158 series.
4 Provided data
4.1 Interface IDtmParameter
The minimum set of provided data should be: Process values modelled as channel objects
including the ranges and scaling.

PAS 62453-3  IEC:2006 – 9 –
4.2 SingleDataAccess interfaces

Via the interfaces IDtmSingleDeviceDataAccess and IDtmSingleInstanceDataAccess at least

all parameters of the Physical Block and the status and Out value of the Function Blocks must

be exposed.
5 Protocol specific usage of XML attributes

Table 1 explains how attributes in documents of the SingleDataAccess interfaces are used

with PROFIBUS protocols.
Table 1 – SingleDataAccessSchema attributes
Attribute Description for use in Profibus
address Profibus Slave Address:
The attribute ‘address’ (defined in FDTDataTypesSchema.xml) follow the
different device models that are defined for PROFIBUS devices. FDT currently
supports following models:
PROFIBUS DP / DPV1,
PROFIBUS PA,
PROFIdrive (greater or equal profile version 3)

PROFIBUS DP / DPV1
The device model is based on devices that are composed of slots, whereas
slots do not have to 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 attribute 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 attribute 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, 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 (normaly slot 0
index 47).
The address attribute is APIxxSLOTyyINDEXzz.DOdo-id.pnu

– 10 – PAS 62453-3  IEC:2006
Attribute Description for use in Profibus

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’

busCategory See Clause 6
deviceTypeId The attribute "fdt:DtmDeviceType/@deviceTypeId" must contain the

IDENT_NUMBER of the supported physical device. The IDENT_NUMBER must
be entered in decimal format, however, the value should be displayed as hex to
the user
deviceTypeInformation A PROFIBUS device has to provide its GSD information as human readable
string at this attribute
NOTE The GSD information is accessible via
IDtmParameter::GetParameters()
IDtmInformation::GetInformation()
deviceTypeInformationPath Path to the file containing the information which is provided via the attribute
‘deviceTypeInformation’.
In case of PROFIBUS the attribute contains the full path to the GSD file
including the file name. The file name depends on the current locale according
to the usage of IDtm::SetLanguage().
For PROFIBUS devices it is mandatory to provide this attribute.

Examples:
English: ‘C:\MyFolder\ABCD.GSE’
German: ‘C:\MyFolder\ABCD.GSG’
manufacturerId Enter manufacturer according to Profile specification, for example in Profibus
PA : Physical Block Index 10 : DEVICE_MAN_ID
semanticId The SemanticIDs for PROFIBUS follow the different device models, that are
defined for PROFIBUS devices. FDT currently supports the following models:
applicationDomain
PROFIBUS DP,
PROFIBUS PA,
PROFIdrive.
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 must be built based on the names defined in the
profiles
Structured parameters must be combined with a ‘.’
Spaces within the profile definition must be exchanged with an
underscore.
Blocks must be counted according to the Object Dictionary

PAS 62453-3  IEC:2006 – 11 –
Attribute Description for use in Profibus

The block number must 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 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 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
PROFIBUS DPV1,
The applicationDomain is: FDT_PROFIBUS_DPV1
The device model is based on devices that are composed of slots, whereas
slots do not have to 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 API
yy Slot
zz Index
xx, yy, zz are based on decimal format without leading ‘0’
subDeviceType Enter manufacturer-specific value here

6 Bus category
Profibus protocol is identified by the following unique identifier in busCategory attributes
within XML BusCategory elements:

BusCategory Element Description
036D1499-387B-11D4-86E1-00E0987270B9 Support of Profibus DP V0 protocol
036D1497-387B-11D4-86E1-00E0987270B9 Support of Profibus DP V1 protocol

– 12 – PAS 62453-3  IEC:2006
Profibus uses the following unique identifier in physicalLayer attributes within XML

PhysicalLayer elements:
PhysicalLayer Element Description

036D1590-387B-11D4-86E1-00E0987270B9 IEC 61158-2 (Profibus PA)

036D1591-387B-11D4-86E1-00E0987270B9 RS485

036D1592-387B-11D4-86E1-00E0987270B9 Fiber

036D1593-387B-11D4-86E1-00E0987270B9 Ethernet

7 Communication schema
Used at: IFdtCommunication::ConnectRequest()
IFdtCommunicationEvents2::OnConnectResponse2()
IFdtCommunication::DisconnectRequest()
IFdtCommunicationEvents::OnDisconnectResponse ()
IFdtCommunication::TransactionRequest()
IFdtCommunicationEvents::OnTransactionResponse)

7.1 DPV0 communication
The XML document contains the address information and the communication data.
The supported services depend on the type of PROFIBUS master functionality that is provided
by the communication infrastructure. Master Class 1 devices typically control the slaves and
provide cyclic communication, Master Class 2 devices typically are used to configure the
slaves and provide acyclic communication.
Not all defined services are supported if the Master is not in cyclic data exchange with the
slaves. In such cases the following behavior is expected.
If a Communication Channel receives a request that can not be supported, it returns the
TransactionRequest() with a result=”false”. (See Tables 2 and 3.)
Table 2 − DPV0CommunicationSchema attributes

Attribute Description
busAddress Address information according to the IEC 61158 series (see also
DTMParameterSchema, attribute busAddress)
connectStatus Describes the connection status established by the communication component.
The status “masterConnectedOnly” means that the communication component has
established a connection to the Profibus master device and will accept an online
access to the user parameters, independent whether the device is available or not.
The Status “deviceAtLifeList” means that the communication component has
established a connection to the Profibus master device and has checked that the
device is in the life list of the master stack. In this state the master will accept an
online access to the user parameters and will send the user parameter to the
device, independent of whether the device is in data-exchange or not.
The status “deviceInDataExchange” means that the communication component has
established a connection to the Profibus master device and has checked that the
device is in data-exchange. In this state the master will accept an online access to
the user parameters and will send the user parameter to the device, so that the
new data will directly influence the process

PAS 62453-3  IEC:2006 – 13 –
Attribute Description
errorCode Status information according to the IEC 61158 series.

For description of error code see:

DIN 19245 Part 3, PROFIBUS (P. 40ff., 83ff., 39)

communicationReference Mandatory identifier for a communication link to a device This identifier is allocated

by the communication component during the connect. The address information has

to be used for all following communication calls

delayTime Delay time in ms between two communication calls

sequenceTime Period of time in ms for the whole sequence

schemaVersion Defines the version of the schema

Table 3 − DPV0CommunicationSchema elements
Tag Description Master
Class
Abort Describes the abort -
ConnectRequest Describes the communication request to establish a connection -
to a Profibus master device.
Depending on the network infrastructure used it is possible that
this service is not mapped to a field bus request, but is used to
manage the software.
It is also possible that this service is used as a trigger to set the
state of a device.
ConnectResponse Describes the communication response to the connect request -
and provides the information on how the following
WriteUserParameter commands will be sent to the device (see
connectStatus).
The resulting connection depends on the communication device
used and on the configuration of the bus master. The DeviceDTM
must expect that the resulting connection cannot be used to
access all services.
ConnectResponse may return true even if there is no
communication with the device possible. For example. if
ConnectRequest returns true with connectionStatus =
“masterConnectedOnly” this means that there is a connection to
the master device, but the device is not at the life list and can
therefore not be accessed. Depending on the connectStatus
some services may not be available (e.g. in status
“masterConnectedOnly” only services provided by the master are
accessible (ReadUserParameter, WriteUserParameter, …)
whereas services provided by the device are not accessible. It
should be noted that in this example the DTM is in state “online”
but it cannot access the device. The provided services also

depend on the type of master device.
For an overview of availability of services depending on the type
of connection, see the following tables
DisconnectRequest Describes the communication request to release a connection to -
a Profibus master device
DisconnectResponse Describes the communication response -
FDT Root tag -
ReadUserParameterRequest Describes the communication request according to the Profibus 1
DPV0 specification.
The request retrieves only the information that is available from
the master device (local service). It may differ from the actual
data of the device. The implementation on how to provide the
data is proprietary.
This is based on a local service or not available

– 14 – PAS 62453-3  IEC:2006
Tag Description Master
Class
ReadUserParameterResponse Describes the communication response, read from the Profibus –

master device, according to the Profibus DPV0 specification. The

returned data may reflect only the information that is available
from the master device. It may differ from the actual data of the

device
WriteUserParameterRequest Describes the communication request according to the Profibus 1, 2

DPV0 specification. The user parameter will be send according to

the established connection (see connectStatus).

For Master Cl. 1 this is based on the service “DDLM_Set_Prm”.

For Master Cl. 2 this is based on the service “DDLM_Set_Prm”

(an optional service)
WriteUserParameterResponse Describes the communication response according to the Profibus -
DPV0 specification
ReadOutputDataRequest Describes the communication request according to the Profibus 1, 2
DPV0 specification
Depending on whether the underlying FDTChannel is a Master
Cl. 1 or a Master Cl. 2 this service will be local or result in a read
access to the slave device. It is possible to specify which data
will be read by providing an fdt:ChannelReference.
For Master Cl. 1 this is a proprietary service (or un-available).
For Master Cl. 2 refer to [1], section 8.2.2.3.6. “Read Output” (an
optional service)
ReadOutputDataResponse Describes the communication response according to the Profibus –
DPV0 specification
SequenceBegin Describes the sequence begin –
SequenceEnd Describes the sequence end –
SequenceStart Describes the sequence start –
WriteOutputDataRequest Describes the communication request according to the Profibus 1
DPV0 specification.
The output data will be sent according to the established
connection.
It is necessary to specify which data will be written by providing
an fdt:ChannelReference.
If the underlying FDTChannel is provided as Master Cl. 2, writing
Output Data will be not possible.
Refer to IEC 61158-5, 8.2.2.3.5: “Set Output”
This functionality depends on the type of master used. In terms of
PLC this functionality is named “forcing” of values
WriteOutputDataResponse Describes the communication response according to the Profibus –

DPV0 specification
ReadInputDataRequest Describes the communication request according to the Profibus 1, 2
DPV0 specification.
Depending on whether the underlying FDTChannel is an Master
Cl. 1 or a Master Cl. 2 this service will be local or result in a read
access to the slave device. It is possible to specify which data is
read by providing an fdt:ChannelReference.
For Master Cl.1 refer to IEC 61158-5, 8.2.2.3.3: “Get Input”.
For Master Cl.2 refer to IEC 61158-5, 8.2.2.3.2: “Read Input”
ReadInputDataResponse Describes the communication response according to the Profibus –
DPV0 specification
ReadDiagnosisDataRequest Describes the communication request according to the Profibus 1, 2
DPV0 specification.
For Master Cl.1 refer to IEC 61158-5, 8.2.3.3.2: “Get slave diag”.
For Master Cl.2 refer to IEC 61158-5, 8.2.3.3.3: “Read slave
diag”
PAS 62453-3  IEC:2006 – 15 –
Tag Description Master
Class
ReadDiagnosisDataResponse Describes the communication response according to the Profibus –

DPV0 specification
Depending on the bus master type and on the returned connectStatus the following services

are available, see Table 4.
Table 4 – Availability of services depending on master and connect status

For Master Class1 (C1)
connectStatus
Slave DTM Service masterConnectedOnly DeviceAtLifeList DeviceInDataExchange
Request
Connect 9 9 9
ReadUserParameter 9 9 9
WriteUserParameter 9 9 9
ReadOutputData  9
WriteOutputData  O
ReadInputData  9
ReadDiagnosisData 9 9
For Master Class2 (C2)
connectStatus
Slave DTM Action masterConnectedOnly DeviceAtLifeList DeviceInDataExchange
Connect 9 9 9
ReadUserParameter 9 9 9
WriteUserParameter 9 9 9
ReadOutputData
WriteOutputData
ReadInputData  9
9 9
ReadDiagnosisData
NOTE
9 means that the service is available;
O means that the service is optional and may be available, depending on the capabilities of the underlying

master device.
xmlns:dt="urn:schemas-microsoft-com:datatypes" xmlns:fdt="x-schema:FDTDataTypesSchema.xml">

















– 16 – PAS 62453-3  IEC:2006






















































































PAS 62453-3  IEC:2006 – 17 –