Through my research I am amazed at the divergence of opinion between companies in relation to the development of the FDT standard. For anybody who is unfamiliar with this standard, it provides true "plug and play" facility within the automation and measuring industry. Complex automation devices can be configured, visualized, controlled and serviced in a central and easy to follow application. Despite the obvious advantages very few companies (except major players) have looked seriously at it. I would be grateful for some opinions as to why??

 

Hello, Owen;
First, here is a website you might look at for a little history of the FDT/DTM standard:
"http://www.controleng.com/archives/news/2001/October/mb1003ikma1.htm":http://www.controleng.com/archives/news/2001/October/mb1003ikma1.htm

This standard is an evolution of Profibus GSD files (product information files)that allows Porfibus network elements to be exchange
specifications on configuration in a project. It was developped to take into acount the more stringent specs of intelligent field devices.
Some german software companises life ifak-systems and mm-software offer Java and C++ packages to write specs iin the FDT standard. I am sure that other fieldbus vendors will develop "standards" of the same level (LON Works and Fieldbus Foundation are presenting something of the kind for their products); but for the moment such developments are still limited by the fieldbus war mentality. Not much hope for
interconnection soon.
Hope this helps,
Daniel Chartier

 

Hi Owen

It's very simple. The same two obvious reasons that control many decisions in this market.

Not Invented Here. Therefore not under complete inhouse control. It can't be diddled with to generate revenues or keep competitors incompatible.

It would allow useful interoperability and make swapping vendors much too easy.

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.

 

One of the obstacles is probably that FDT is considered to be "Profibus", and not suitable for
anything else. Recently the PTO (Profibus Trade Organisation) has given the intellectual rights
to FDT back to the German ZVEI, who -hopefully- do something to promote FDT further. As far as I know, the ZVEI (Central Organisation for the Electronical Industry) originally 'invented' FDT, but contracted it out to the PTO to implement it.

A second obstacle (I thnk) is that FDT is considered only good for process automation,
not machine automation. Perhaps the latter have no need for FDT-style functionality?

The idea to have all network- and/or device-functionality hidden in a 'DTM' (Device Type
Manager) is undoubtedly clever, but not very much more clever than (say) having printer drivers on a PC. The printer driver takes care of all the low-level details, and one can also incorporate some intelligence in the driver to handle specific tricks. You can do similar things with the DTM in FDT. After all, it is just a program like anything else.

The advantage of FDT is that it allows a more integrated data handling, so you
don't
have to configure all devices separately, and manually cut-and-paste the
information to
your PLC's programming package, with all the issues of having duplicate data.

Note, btw, there are already implementations of FDT, such as PactWare. Another initiative is FDCML (Field Device Configuration Markup Language), but this seems to be younger than FDT, and I haven't heard much about it. Both have websites on "www.fdcml.org":http://www.fdcml.org and "www.pactware.org":http://www.pactware.org

Greetings,
Rob Hulsebos

 

I think PactWare started before the FDT spec was "official" for implementation. There is one company that is doing work on it and have an
implementation, it is M&M Software LTD, see "http://www.mm-software.de":http://www.mm-software.de .
There are two problems with FDT/DTM: Siemen's adding an FDT to their programming environment and the newest specs only being in German. You can get the 1.2 specs from the Profibus organization but there is still being work done on it.

I would see how the FDT/DTM presentations go at Hanover Fair before deciding if this standard is going to go anywhere.

Darryl Palmer

 

FDT DTM

This response is well 'after the fact' of your post. I came accross it looking for political comments on FDT/DTM. I read all the responses to date to the post. FDT/DTM extends the concept of field device configuration. Whereas a HART DD or a Profibus EDD can totally describe device functiooaliuty as a collection of data. FDT/DTM extends this by providing the visualisation as well. This is scary to some control system manufactures as they see themselves losing control of the look and feel of their platform environments. In an FF environment for (let us say) an Endress + Hauser radar level transmitter. The DD for FF could have functionality to read the echo curve. The problem is the visualisation of that curve on the host. This functionality is not handles in the hosts interpretation of the DD. Thus the current situation of best fit profiles that do not allow specific device innovations to be viewed and interacted with is almost copmpletely addressed with the open tooling concept of FDT/DTM.

The tools now exist to convert HART DD's to DTMs. In April next year Profibus DTMs will start to become available opennly and we will start to the benefits of real interoperability for instrument configuration.

In my opinion the FDT/DTM concept scares many of the DCS manufactures rigid. However if bodies like FF do not get involved in it or a similair concept then they seriously jepordise implimentation of their technologies by users.

Through my research I am amazed at the divergence of opinion between companies in relation to the development of the FDT standard. For anybody who is unfamiliar with this standard, it provides true "plug and play" facility within the automation and measuring industry. Complex automation devices can be configured, visualized, controlled and serviced in a central and easy to follow application. Despite the obvious advantages very few companies (except major players) have looked seriously at it. I would be grateful for some opinions as to why??

 

> FDT DTM

It is plug and pray - how we know it from Windows.

There is no stable standard of FDT and no implementation as such a stable standard in a system.
May be there exists some prototypes.

That's plug and play/pray - how we know it from Bill Gates.

 

Some statements about FDT/DTM :

FDT (Field Device Tool) is an open, stable specification which defines interfaces between
device operation components (DTM = Device Type Manager) and tool applications.
The latest version is FDT 1.2 + Addendum (and it is available in English).

The FDT/DTM concept contains three main parts:
Device DTM, Comm DTM and a frame application.
The DTM provides complete graphical device operation.
The Comm DTM provides in addition communication protocol dependent functionality.
The frame application is responsible for managing the DTMs, the data persistency, the network topology and so on...

The FDT/DTM concept will not replace the DD, but enhance and bring it to an higher level.
The German company “Codewrights” GmbH has a tool to generate a DTM out of a DD.

The main advantage of FDT is openness, which means that the customer can operate devices from different manufactures and with different communication protocols in one tool, even in one project. Also vertical integration trough gateways and remote I/O´s is possible.

FDT is not bound to a specific communication protocol, today already exist DTMs for HART, Profibus and on prototype level for FF.

The list of companies which support FDT is long and grows daily.
So FDT will become a powerful technology in the market.