FieldComm Group Forums for FOUNDATION Fieldbus technology  

Go Back   FieldComm Group Forums for FOUNDATION Fieldbus technology > Public Forums > Fieldbus User's Network [FUN]

Fieldbus User's Network [FUN] The Fieldbus User Network List Forum. Post your fieldbus related questions here.

Thread Tools Display Modes
Prev Previous Post   Next Post Next
Old August 12th, 2003, 12:24 PM
Stephen Mitschke's Avatar
Stephen Mitschke Stephen Mitschke is offline
Admin / Fieldbus Staff
Join Date: Jun 2003
Posts: 472
FDT and DD

I have also pasted the balance of this thread to the note as I am not sure
if everyone got ALL of it. Thanks for your patience folks.
-----Original Message-----
Hello Ian,
I have been following the discussion on FDT/DTM and DD/CFF.
As ABB was directly mentioned in the discussion, I thought that it would be
appropriate to express our point of view. So, we asked Stefan Bollmeyer to
respond and give the position of our development guys. Here it is.
(See attached file: FUN FDT Statement ABB_d2.doc)
Could you post it on FUN as our contribution to this ongoing exchange.
Could you also put Karl-Heinz and Stefan on the FUN address list?
Flavio Toflo, ABB,
- - - - - November 19 ------
The PACTware consortium was announced at Interkama in September and
information on the group can be found at I do not
know of anyone who has written a Foundation Fieldbus driver yet but they
have been written for other protocols such as HART and Profibus. I think The
Foundation is hoping/planning that OPC DX will fulfill the similar need and
make PACTware less of an issue.
Syncrude Canada Ltd.
PO Bag 4009, MD 0032
Fort McMurray, AB T9H 3L1
P 780 790-4079, Cell -799-6017
F 780 790-5190
-----Original Message-----
From: Sprague, Jim L
Hi Ian,
I've been hearing about the development of a common 'Field Device Tool'
(FDT) that is supposed to unify the engineering tools required to set-up
and commissioning of fieldbus devices. It appears Profibus is
supporting development of this tool, and that Yoko, ABB, Foxboro appear
to be working on including it in their DCS. I've also heard that
Emerson is specifically not supporting it.
I'd like to hear more about this tool, what it does, and it's
implications for FOUNDATION Fieldbus. We use Yoko, ABB, Foxboro,
Honeywell, & Emerson DCS system, and I'd like to hear from these on
whether these guys are supporting this FDT 'technology' - why/why not.
Jim Sprague
Saudi Aramco
- - - - November 20 - - -
Few things to clarify here. PACTware Consortium is a commercial
(non-profit) organization the mission of which is to make a FDT based
stand-alone configuration tool for process automation devices. This tool is
named PACTware (registered trademark) and the core part of the tool is
available as source code. PACTware Consortium utilizes the FDT
specification coming out from PNO (Profibus Organisation).
The FDT specification is developed under PNO and the working group is
headed by ABB. There is some information at
specifies the interfaces of the software components used for device
configuration and diagnostics which are called DTMs (Device Type Manager)
and the corresponding interfaces of a "FDT frame application" which manages
DTMs. DTMs are basically provided by the device vendors like DDs (Device
Descriptions) are provided nowadays. FDT frame application can be an
engineering tool, asset management tool, operator interface or any other
process automation application software which utilizes the functionality of
the intelligent process automation devices (network devices, transmitters,
actuators etc.). FDT is fieldbus independent and can handle simultaneously
different fieldbuses including HART. Fieldbus support requires just a
standard XML schema to be published by FDT working group. At the moment XML
schemas for HART and PROFIBUS has been published. There is a common need to
publish FOUNDATION fieldbus schema but the schedule is not planned yet.
FDT provides a way without any limitations to integrate device
functionality (configuration and diagnostics) into a corresponding tool
utilizing this functionality. It is operating at the lower level than OPC
and does not limit the functionality for configuration and diagnostics
related to setup and commissioning as OPC presently does. It is not clear
if OPC DX will solve that problem.
Best regards
Kari Hartikainen
Metso Endress+Hauser Technology AG
- - - -
I have looked at the PACTware web site and attempted to understand what
it is. First, PACTware is a Visual Basic program for the PC. I
downloaded the demo version, but it does not help much unless you have a
HART or Profibus device connected. I "think" that it is a user-level
program allowing you to configure any of the supported devices such as
HART or Profibus from a Windows Explorer-like program that displays all
of the device attributes or parameters from this display rather than
from a proprietary HMI or a Handheld terminal. I don't see anything
about serving as a programming API or device interface.
OPC DX will be completely different. DX is an extension of OPC DA to
enable access to data by tag name and attribute. It WILL be fully
supported by Foundation Fieldbus and I expect the Foundation to convert
all of the DD structures to DX XML schemas. All suppliers of devices
with DD's not supported by the Foundation should also convert their DD's
to XML. I expect that there will be sample code for these schemas early
next year, and there may even be a conversion tool from DD to XML
schema. But, DX is a developer tool, not an end user tool. By the way,
I expect that the PNO will supply a full set of DX XML schemas for the
Profibus-PA devices and a Profibus OPC DX server.
Dick Caro
Richard H. Caro, Vice President
ARC Advisory Group
- - - - -
My understanding is that Hart Communication Foundation has not released any
XML solution. To the best of my knowledge, most of the XML schemas
available don't handle conditionals and other complex device data
Any XML schema for Foundation Fieldbus or HART must allow complete
implementation of DD technology, I don't know of any solution that meets
this requirement yet.
I would like to read the XML specifications mentioned in the recent
postings, can someone please provide a link?
+Sean Vincent
Fieldbus Inc.
- - - - November 21 - - - - -
If you refer to the XML schemas used in the FDT concept they have nothing
to do with the business logics of a device. Rather they map the
communication protocol into XML structure which is used for the data
transfer between DTMs using that communication protocol. All the business
logics of a device resides in a DTM.
Unfortunately these XML schemas are at the moment only available for
Profibus members.
Kari Hartikainen
Endress & Hauser
- - - -
Dear All,
The FDT/DTM is a Profibus method for device parameterization to create
interoperability for the host until now not available. FOUNDATION(tm)
Fieldbus uses DD instead. Both DTM and DD are means to interpret semantics
(e.g. 16 = "Manual") of data and present it to the user. The DTM (Device
Type Manager) is some kind of Windows ActiveX application that runs in a
"container" FDT (Field Device Tool) that provides the communication services
through the hardware. I.e. you install DTMs for every device type in the FDT
you are using. The DTM application is programmed by the manufacturer to
interpret the device data and display it to the user with a manufacturer
specific look and feel (although there is a "style guide" trying to create
some consistency).
The DTM mechanism has some pros and cons as compared to the DD mechanism:
DTM can only run under Windows (it may be OK to exclude handhelds and Unix).
The look and feel is not as consistent as with DD. However, the benefit is
that the manufacturer can program DTM graphics for sophisticated diagnostics
such as X-Y plots, plots over time, histograms or Pareto charts to run on
any FDT host. This can be used for valve diagnostics such as valve signature
etc. DD has Menu and some other means for the defining how data should be
organized but nothing for advanced graphics. I don't think FDT/DTM handles
function block instantiation and linking so in the current form it may not
provide all the functionality required in an FF host.
OPC DX does not handle semantics or presentation. OPC DX just transfers data
from one place to another, it does not describe what the data means or how
it should be presented. It is essentially a means to configure two OPC DA
servers to connect to each other. OPC DX proposal is pretty much the exact
same thing as the PROFInet proposal. The PROFInet Ethernet concept is quite
different from the HSE Ethernet solution. I guess the OPC DA version 3, OPC
complex data, or OPC XML transport etc. will solve the issue of data types
to represent function blocks but I don't think presentation graphics will be
To complement DD parameterization with plots etc. on computers some form of
additional FF technology may be required. Also required would be means to
store and retrieve such information on the host for comparison.
The last time I checked the FDT/DTM profile was still a draft.
Jonas Berge (Smar)
- - - -
It is difficult at present to get a comprehensive user-oriented overview of
FDT, so here is some further clarification;
actually the October issue of Control Engineering Europe has quite a good
article about FDT, along with a news item about OPC-DX
1. Although the specification is now managed by the Profibus organisation,
it's origin was a technical proposal produced by the ZVEI German trade
organisation on behalf of a multi-vendor consortium backed by some key
users like BASF (who hosted the first installation).
Support for FF devices is a declared objective, though the initial focus
has been HART & Profibus.
2. The concept behind FDT is to make connecting field devices and I/O "as
easy as connecting a printer to a PC/Windows". That means the vendor
provides the "driver software" (DTM) that contains not just knowledge of
the device but also includes the user interface; it may also include
diagnostic and other value-added facilities, just like my home printer
driver provides a status indicator, out-of-paper warnings and a
head-cleaning utility.
3. FDT relies on COM/Active-X technology, and device data managed by the
DTM is made available to the frame via XML schemas.
4. The frame application is responsible for network configuration,
navigation and storing device data.
This can be part of a system engineering tool (e.g. ABB) or, for the
smaller vendors, Pactware
5. Pactware is "Open-source" software - this is believed to be a "first"
in the world of automation.
"DTM studio" Software is already available from at least one associate
company to generate DTMs from HART Device Descriptions.
6. The DTM is responsible for management of field devices and intervening
network components like DP/PA links and HART Mux; the DTM provides the
means to parameterise the device, and also provides the communication
driver; it depends on the network supporting "pass-through" messaging
A concept of "nested DTMs" allows the frame to establish a communication
path through a complex network topology comprising, foe example, a DP
interface card, DP/PA link, I/O subsystem gateway, AI+HART module, down to
the device itself.
In short, FDT is the only non-proprietary technology I know that tries to
standardise the environment for configuring system components.
I believe there are potential synergies between the OPC-XML initiative and
John Halliday
Endress+Hauser Process Solutions
- - - - - - -
Hello All,
Thanks to John Halliday for his clear explanation of the FDT concept. My
understanding of it, is along similar lines to his, in that it is much more
than a parameterised XML representation of device specific features. In my
view, the FDT concept is an excellent idea whose time has not only come, but
is in fact way overdue.
For anyone who is interested, here is a more detailed explanation as to why
I feel the concept is so significant. I welcome correction, should I be in
error on any technical points.
I previously worked as bus communications product manager for Danfoss
Instrumentation and was introduced to the FDT concept in Germany during 1999
and 2000 by enthusiastic supporters of it from Pepperl+Fuchs, and another
German company, ICS. The reason it had immediate appeal to me at that time
was because the concept appeared to address a nagging issue for those
manufacturers who produce good fieldbus capable instrumentation, but do not
produce host systems and associated software. These manufacturers (and there
are a number of them), have to form what some people call "unholy alliances"
with the vendors of the popular host systems in order to develop drivers for
the many and varied "flavours" of host system software. The process can be
very costly and time consuming, and raises competitive issues such as how
many, and which specific host packages to support, plus the intricacies of
dealing with host system vendors who can supply the field instrumentation as
well, - a point not lost by sales people when compatibility issues arise!.
This also affects the customers (end users) who are learning that a so
called "open protocol" doesn't count for much when a device they would like
to buy is not supported in the driver list for the specific host system they
are using, or intend to use. Worse still, is that some customers (and
numerous vendor sales people) do not always fully understand the limitations
of generic command sets versus full device specific functionality. The
result can be a frustrated customer who is bitterly disappointed that
demonstrated features he wants to utilise in the device are not accessible
through his chosen host system software, for the fieldbus protocol he
thought was "open".
Where FDT and OPC seem to differ is that OPC concerns itself more with the
free exchange of live process data between Windows based applications, and
to a much lessor extent the configuration of the specific field devices
providing the data. This is why we see all manner of OPC servers for
hardware and applications of a type that could be described as "channels"
for a protocol, for example PLC's, DCS's, various bridges and gateways, DDE
services etc, but almost never for the actual field instrumentation itself.
With OPC, you are limited to what extent you can configure the field device,
by the OPC server tag list which depending on the protocol, may or may not
adequately cover the range of functions supported in the field device. In
essence this tag list is a generic command set relevant to the channel,
is derived from the particular protocol and associated channel hardware.
Because FDT is concerned with device specific information, as well as the
communications protocol, this is why it is said to be working at a "lower
level" than OPC.
If I understand it correctly, what FDT/DTM offers, is an application
independent device driver with a standardised interface to any FDT compliant
application, plus management of the communications channel. On the surface
an OPC based FF system running a conventional DD application, could claim to
fit this model as well. But the major difference relates to which side of
the application the field device driver resides.
In the FDT model a single driver for the device is on the communications
channel and available to any compliant applications (this is where the
analogy to a windows printer driver comes from). However, with present DD
models the device drivers are custom written for integration into the host
applications which then either directly manage the communications channel,
or connect as clients to an OPC server that manages the channel. Because the
DD is on the "the other side" of the client application with respect to the
OPC server, the device specific features the DD supports will not be
available to other OPC clients, unless;
a) The client application into which the DD has been integrated, can add
device specific tags to the respective OPC server. Usually OPC servers that
allow this, are from the same vendor as the client application (or at least
a very closely aligned).
b) The application may be double ended, meaning it can present itself as an
OPC client to the main server, but as an OPC server to other clients.
The key point is that with the conventional DD and OPC approach, a major
host application must be present BEFORE any device specific information can
be made accessible to the larger system. With FDT the device driver and
relevant channel driver is simply there waiting for any compliant
application, whether "big" (e.g. a major host system application) or "small"
(free to use PactWare) to connect up to it.
So where does this leave OPC, and the present "big" non-FDT host system
applications that have become increasingly reliant on OPC?
Well, here's two "off the wall" suggestions.
1) Why not everyone aim to cooperate to make FDT the preferred device driver
and communications channel interface?
This would involve:
a) A working party to be established of experienced FF developers with a
mandate to properly evaluate the real strengths and weaknesses of FDT, and
report back within a reasonable time frame. Assuming a positive outcome then
b) Set up a joint effort on the development of a FF DTM, (which should
not be too onerous given that ones have already been worked out for Profibus
and HART)
c) Promote the development of DTM type device descriptions for enough
products to ensure the system reaches a critical mass of support. Given that
the DTM Studio tool for converting HART device descriptions to DTM already
exists, this should be relatively easy for HART device manufacturers.
Furthermore, due to the close family history of HART and the FF DD language,
conversion of the HART DTM Studio tool to work with FF DD's should also be a
reasonable task.
2) And here's the big one........ To prevent the established host system
software vendors from having their noses put right out of joint, encourage
those who wish to develop an FDT interface to do so, and for the rest
DEVELOP AN FDT to OPC SERVER. I am sure Iconics, Merz, Matrikon, Softing etc
would be quite capable of doing a good job of this.
Wayne Gray-Garney
Process Control Support
CHH Tasman Pulp
- - - - -
Hi All,
I've been following the discussion on FDT/DTM and felt a reply was needed
from the FF.
Quote from Rich Timoney, President of the FF, "We support the OPC initiative
to develop a tool for exchanging data between servers for those users who
have a need to do so. This does not change our position in regard to the
Device Description (DD) technology. XML although a promising technology at
this time may or may not be the right direction for the Fieldbus Foundation
to follow at some point in the future. If it appears appropriate we will
address it at the appropriate time."
Now a bit about the differences between DD and XML (FDT/DTM):
The FF is looking at several different future technologies, and_currently_
none of these technologies are a direct replacement for DD's.
XML can not do everything that are done by DD's. XML is a great way to get
information displayed on a Windows based host in a common way, but does not
do some of the more advanced functions like conditionals and logic that are
performed by the DD.
Currently, DD's, along with DD Services (DDS. It runs on the host) and
Capability Files provide the same and more capability than FDT/DTM. In my
opinion, FDT/DTM is a great technology for simple discrete devices, but
lacks the capability of handling complex FF devices.
Looking at the feature list for FDT/DTM, the DD/CFF technology can currently
support every feature listed for FTD/DTM, but the DD technology has more:
- Online AND off-line configuration support (FTD/DTM is off-line only)
- Conditionals and logic
- Is a proven technology that has been around for years
- FF has the capability of uploading and downloading DD's and new firmware
directly to/from a device.
In my opinion, I see XML working _WITH_ the DD technology, not replacing it.
i.e. using XML to interface with DDS and "execute" DD's and display them on
a host. But who knows about the future, maybe XML can be extended to do
other "things" similar to what DD's accomplish. Microsoft is still working
on it's "Dot Net" strategy, so who knows what Big Bill will do.
This is why the FF is researching many different technologies for the
future, but right now the DD technology can't be beat for what it does...
Note: The _opinions_ expressed here are my own and do not necessarily
represent those of the Fieldbus Foundation and it's members. The facts
represent themselves...
Kurt Zech
Manager, Technical Services
Fieldbus Foundation
- - - -
I did not want to compare DD technology with FDT technology because I feel
both are needed but you started. I have some background on FF and FDT and
would like to correct/clarify some of your statements. It is unfortunate
that FDT technology is developed more or less behind the closed doors and
the publicly available material provide impression that it is only for
Profibus (Jonas: FDT specification ver. 1.2 was released this year and
corresponding products are expected 2002).
First of all, you have to understand the analogy between DD and FDT
technology. In this case DD Services are analogous to FDT frame application
interfaces defined in FDT specification and DDs+CFFs are analogous to DTMs.
The technology used to implement the specification includes COM, ActiveX
and XML. For example XML in FDT has nothing to do with the functionality
provided by a DD which I call the business logics of device
parameterization. So instead of comparing DD with XML you must compare DD
with DTM.
Now to your statements:
> DD technology has more:
> - Online AND off-line configuration support (FTD/DTM is off-line only)
A DTM can operate both online and off-line.
> - Conditionals and logic
Conditionals and logic are implemented in a DTM by using standard
programming language (e.g. C++). As we know DD is not as powerful as native
computer programming language. In addition to that ActiveX provides
powerful mechanism for GUI implementation lacking totally from DD language.
So I would say DTM can handle complex devices but for simple devices it is
> - Is a proven technology that has been around for years
Except CFF. There are many hosts out there who still do not support the
final CFF specification which was released beginning of this year.
> - FF has the capability of uploading and downloading DD's and new
> firmware directly to/from a device.
I think this is more related to the functionality of FF communication
protocol and not to the DD technology.
Some of the advantages of the FDT are:
- Standard approach to network engineering
- Provides full network configuration capabilities when network devices
include DTMs (maybe not useful for FF because of Plug'n Play)
- Unlimited handling of complex devices
- Powerful applications can be easily embedded to assist in the setup and
maintenance of a device
- Single FDT frame application can handle different field networks
Some of the disadvantages of the FDT are:
- Overkill for simple devices i.e. DD is more simple way to make device
interface and adequate enough
- DTMs encapsulate the device data semantics and business logics (at the
Advantages and disadvantages depend on the viewpoint and the above list
mixes them freely and is not as such useful for decision making.
I believe both DD and FDT technology has a role in the automation without
any impact to end user. The optimal solution would be taking the best out
of both technologies.
Kari Hartikainen
Metso Endress+Hauser Technology AG
Attached Files
File Type: doc FUN FDT Statement ABB_d2.doc (26.5 KB, 339 views)


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

All times are GMT -5. The time now is 02:05 PM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
(c) 2011-2015 by FieldComm Group. All rights reserved.