[fun] Fdt/dtm

[Stephen Mitschke]

Hello All,Thanks to John Halliday for his clear explanation of the FDT concept. Myunderstanding of it, is along similar lines to his, in that it is much morethan a parameterised XML representation of device specific features. In myview, the FDT concept is an excellent idea whose time has not only come, butis in fact way overdue.For anyone who is interested, here is a more detailed explanation as to whyI feel the concept is so significant. I welcome correction, should I be inerror on any technical points.I previously worked as bus communications product manager for DanfossInstrumentation and was introduced to the FDT concept in Germany during 1999and 2000 by enthusiastic supporters of it from Pepperl+Fuchs, and anotherGerman company, ICS. The reason it had immediate appeal to me at that timewas because the concept appeared to address a nagging issue for thosemanufacturers who produce good fieldbus capable instrumentation, but do notproduce host systems and associated software. These manufacturers (and thereare 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 forthe many and varied "flavours" of host system software. The process can bevery costly and time consuming, and raises competitive issues such as howmany, and which specific host packages to support, plus the intricacies ofdealing with host system vendors who can supply the field instrumentation aswell, - a point not lost by sales people when compatibility issues arise!.This also affects the customers (end users) who are learning that a socalled "open protocol" doesn't count for much when a device they would liketo buy is not supported in the driver list for the specific host system theyare using, or intend to use. Worse still, is that some customers (andnumerous vendor sales people) do not always fully understand the limitationsof generic command sets versus full device specific functionality. Theresult can be a frustrated customer who is bitterly disappointed thatdemonstrated features he wants to utilise in the device are not accessiblethrough his chosen host system software, for the fieldbus protocol hethought was "open".Where FDT and OPC seem to differ is that OPC concerns itself more with thefree exchange of live process data between Windows based applications, andto a much lessor extent the configuration of the specific field devicesproviding the data. This is why we see all manner of OPC servers forhardware and applications of a type that could be described as "channels"for a protocol, for example PLC's, DCS's, various bridges and gateways, DDEservices 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 notadequately cover the range of functions supported in the field device. Inessence this taglist is a generic command set relevant to the channel, whichis derived from the particular protocol and associated channel hardware.Because FDT is concerned with device specific information, as well as thecommunications protocol, this is why it is said to be working at a "lowerlevel" than OPC.If I understand it correctly, what FDT/DTM offers, is an applicationindependent device driver with a standardised interface to any FDT compliantapplication, plus management of the communications channel. On the surfacean OPC based FF system running a conventional DD application, could claim tofit this model as well. But the major difference relates to which side ofthe application the field device driver resides.In the FDT model a single driver for the device is on the communicationschannel and available to any compliant applications (this is where theanalogy to a windows printer driver comes from). However, with present DDmodels the device drivers are custom written for integration into the hostapplications which then either directly manage the communications channel,or connect as clients to an OPC server that manages the channel. Because theDD is on the "the other side" of the client application with respect to theOPC server, the device specific features the DD supports will not beavailable to other OPC clients, unless;a) The client application into which the DD has been integrated, can adddevice specific tags to the respective OPC server. Usually OPC servers thatallow this, are from the same vendor as the client application (or at leasta very closely aligned).b) The application may be double ended, meaning it can present itself as anOPC 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 majorhost application must be present BEFORE any device specific information canbe made accessible to the larger system. With FDT the device driver andrelevant channel driver is simply there waiting for any compliantapplication, whether "big" (eg 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 systemapplications 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 driverand communications channel interface?This would involve:a) A working party to be established of experienced FF developers with amandate to properly evaluate the real strengths and weaknesses of FDT, andreport 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 shouldnot be too onerous given that ones have already been worked out for Profibusand HART)c) Promote the development of DTM type device descriptions for enoughproducts to ensure the system reaches a critical mass of support. Given thatthe DTM Studio tool for converting HART device descriptions to DTM alreadyexists, 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 areasonable task.2) And here's the big one........ To prevent the established host systemsoftware vendors from having their noses put right out of joint, encouragethose who wish to develop an FDT interface to do so, and for the restDEVELOP AN FDT to OPC SERVER. I am sure Iconics, Merz, Matrikon, Softing etcwould be quite capable of doing a good job of this.Wayne Gray-GarneyProcess Control SupportCHH Tasman Pulp