Stephen Mitschke
August 12th, 2003, 01:24 PM
I have also pasted the balance of this thread to the note as I am not sureif everyone got ALL of it. Thanks for your patience folks.Ian-----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 beappropriate to express our point of view. So, we asked Stefan Bollmeyer torespond 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?Thanks,Flavio Toflo, ABB,- - - - - November 19 ------The PACTware consortium was announced at Interkama in September andinformation on the group can be found at http://www.pactware.com I do notknow of anyone who has written a Foundation Fieldbus driver yet but theyhave been written for other protocols such as HART and Profibus. I think TheFoundation is hoping/planning that OPC DX will fulfill the similar need andmake PACTware less of an issue.IanSyncrude Canada Ltd.PO Bag 4009, MD 0032Fort McMurray, AB T9H 3L1P 780 790-4079, Cell -799-6017F 780 790-5190verhappen.ian@syncrude.com-----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-upand commissioning of fieldbus devices. It appears Profibus issupporting development of this tool, and that Yoko, ABB, Foxboro appearto be working on including it in their DCS. I've also heard thatEmerson is specifically not supporting it.I'd like to hear more about this tool, what it does, and it'simplications for FOUNDATION Fieldbus. We use Yoko, ABB, Foxboro,Honeywell, & Emerson DCS system, and I'd like to hear from these onwhether these guys are supporting this FDT 'technology' - why/why not. Jim SpragueSaudi Aramco- - - - November 20 - - - Hello,Few things to clarify here. PACTware Consortium is a commercial(non-profit) organization the mission of which is to make a FDT basedstand-alone configuration tool for process automation devices. This tool isnamed PACTware (registered trademark) and the core part of the tool isavailable as source code. PACTware Consortium utilizes the FDTspecification coming out from PNO (Profibus Organisation).The FDT specification is developed under PNO and the working group isheaded by ABB. There is some information at www.profibus.com.FDT specifies the interfaces of the software components used for deviceconfiguration and diagnostics which are called DTMs (Device Type Manager)and the corresponding interfaces of a "FDT frame application" which managesDTMs. DTMs are basically provided by the device vendors like DDs (DeviceDescriptions) are provided nowadays. FDT frame application can be anengineering tool, asset management tool, operator interface or any otherprocess automation application software which utilizes the functionality ofthe intelligent process automation devices (network devices, transmitters,actuators etc.). FDT is fieldbus independent and can handle simultaneouslydifferent fieldbuses including HART. Fieldbus support requires just astandard XML schema to be published by FDT working group. At the moment XMLschemas for HART and PROFIBUS has been published. There is a common need topublish FOUNDATION fieldbus schema but the schedule is not planned yet.FDT provides a way without any limitations to integrate devicefunctionality (configuration and diagnostics) into a corresponding toolutilizing this functionality. It is operating at the lower level than OPCand does not limit the functionality for configuration and diagnosticsrelated to setup and commissioning as OPC presently does. It is not clearif OPC DX will solve that problem.Best regardsKari HartikainenMetso Endress+Hauser Technology AG- - - - Ian,I have looked at the PACTware web site and attempted to understand whatit is. First, PACTware is a Visual Basic program for the PC. Idownloaded the demo version, but it does not help much unless you have aHART or Profibus device connected. I "think" that it is a user-levelprogram allowing you to configure any of the supported devices such asHART or Profibus from a Windows Explorer-like program that displays allof the device attributes or parameters from this display rather thanfrom a proprietary HMI or a Handheld terminal. I don't see anythingabout serving as a programming API or device interface. OPC DX will be completely different. DX is an extension of OPC DA toenable access to data by tag name and attribute. It WILL be fullysupported by Foundation Fieldbus and I expect the Foundation to convertall of the DD structures to DX XML schemas. All suppliers of deviceswith DD's not supported by the Foundation should also convert their DD'sto XML. I expect that there will be sample code for these schemas earlynext year, and there may even be a conversion tool from DD to XMLschema. 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 theProfibus-PA devices and a Profibus OPC DX server.Dick Caro============================================Ri chard H. Caro, Vice PresidentARC Advisory Group- - - - -My understanding is that Hart Communication Foundation has not released anyXML solution. To the best of my knowledge, most of the XML schemasavailable don't handle conditionals and other complex device datarelationships.Any XML schema for Foundation Fieldbus or HART must allow completeimplementation of DD technology, I don't know of any solution that meetsthis requirement yet.I would like to read the XML specifications mentioned in the recentpostings, can someone please provide a link?+Sean VincentFieldbus Inc.- - - - November 21 - - - - - Sean,If you refer to the XML schemas used in the FDT concept they have nothingto do with the business logics of a device. Rather they map thecommunication protocol into XML structure which is used for the datatransfer between DTMs using that communication protocol. All the businesslogics of a device resides in a DTM.Unfortunately these XML schemas are at the moment only available forProfibus members.RegardsKari HartikainenEndress & Hauser- - - - Dear All,The FDT/DTM is a Profibus method for device parameterization to createinteroperability 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 (DeviceType Manager) is some kind of Windows ActiveX application that runs in a"container" FDT (Field Device Tool) that provides the communication servicesthrough the hardware. I.e. you install DTMs for every device type in the FDTyou are using. The DTM application is programmed by the manufacturer tointerpret the device data and display it to the user with a manufacturerspecific look and feel (although there is a "style guide" trying to createsome 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 isthat the manufacturer can program DTM graphics for sophisticated diagnosticssuch as X-Y plots, plots over time, histograms or Pareto charts to run onany FDT host. This can be used for valve diagnostics such as valve signatureetc. DD has Menu and some other means for the defining how data should beorganized but nothing for advanced graphics. I don't think FDT/DTM handlesfunction block instantiation and linking so in the current form it may notprovide all the functionality required in an FF host.OPC DX does not handle semantics or presentation. OPC DX just transfers datafrom one place to another, it does not describe what the data means or howit should be presented. It is essentially a means to configure two OPC DAservers to connect to each other. OPC DX proposal is pretty much the exactsame thing as the PROFInet proposal. The PROFInet Ethernet concept is quitedifferent from the HSE Ethernet solution. I guess the OPC DA version 3, OPCcomplex data, or OPC XML transport etc. will solve the issue of data typesto represent function blocks but I don't think presentation graphics will behandled.To complement DD parameterization with plots etc. on computers some form ofadditional FF technology may be required. Also required would be means tostore 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 ofFDT, so here is some further clarification;actually the October issue of Control Engineering Europe has quite a goodarticle about FDT, along with a news item about OPC-DX1. Although the specification is now managed by the Profibus organisation,it's origin was a technical proposal produced by the ZVEI German tradeorganisation on behalf of a multi-vendor consortium backed by some keyusers like BASF (who hosted the first installation).Support for FF devices is a declared objective, though the initial focushas been HART & Profibus.2. The concept behind FDT is to make connecting field devices and I/O "aseasy as connecting a printer to a PC/Windows". That means the vendorprovides the "driver software" (DTM) that contains not just knowledge ofthe device but also includes the user interface; it may also includediagnostic and other value-added facilities, just like my home printerdriver provides a status indicator, out-of-paper warnings and ahead-cleaning utility.3. FDT relies on COM/Active-X technology, and device data managed by theDTM 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 thesmaller vendors, Pactware5. 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 associatecompany to generate DTMs from HART Device Descriptions.6. The DTM is responsible for management of field devices and interveningnetwork components like DP/PA links and HART Mux; the DTM provides themeans to parameterise the device, and also provides the communicationdriver; it depends on the network supporting "pass-through" messagingA concept of "nested DTMs" allows the frame to establish a communicationpath through a complex network topology comprising, foe example, a DPinterface card, DP/PA link, I/O subsystem gateway, AI+HART module, down tothe device itself.In short, FDT is the only non-proprietary technology I know that tries tostandardise the environment for configuring system components.I believe there are potential synergies between the OPC-XML initiative andFDT.John HallidayEndress+Hauser Process Solutions- - - - - - - 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 tag list 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" (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 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- - - - -Hi All,I've been following the discussion on FDT/DTM and felt a reply was neededfrom the FF.Quote from Rich Timoney, President of the FF, "We support the OPC initiativeto develop a tool for exchanging data between servers for those users whohave a need to do so. This does not change our position in regard to theDevice Description (DD) technology. XML although a promising technology atthis time may or may not be the right direction for the Fieldbus Foundationto follow at some point in the future. If it appears appropriate we willaddress 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 getinformation displayed on a Windows based host in a common way, but does notdo some of the more advanced functions like conditionals and logic that areperformed by the DD.Currently, DD's, along with DD Services (DDS. It runs on the host) andCapability Files provide the same and more capability than FDT/DTM. In myopinion, FDT/DTM is a great technology for simple discrete devices, butlacks the capability of handling complex FF devices. Looking at the feature list for FDT/DTM, the DD/CFF technology can currentlysupport 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 firmwaredirectly 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 ona host. But who knows about the future, maybe XML can be extended to doother "things" similar to what DD's accomplish. Microsoft is still workingon it's "Dot Net" strategy, so who knows what Big Bill will do.This is why the FF is researching many different technologies for thefuture, but right now the DD technology can't be beat for what it does...Regards,KurtNote: The _opinions_ expressed here are my own and do not necessarilyrepresent those of the Fieldbus Foundation and it's members. The factsrepresent themselves...Kurt ZechManager, Technical ServicesFieldbus Foundation- - - - Kurt,I did not want to compare DD technology with FDT technology because I feelboth are needed but you started. I have some background on FF and FDT andwould like to correct/clarify some of your statements. It is unfortunatethat FDT technology is developed more or less behind the closed doors andthe publicly available material provide impression that it is only forProfibus (Jonas: FDT specification ver. 1.2 was released this year andcorresponding products are expected 2002).First of all, you have to understand the analogy between DD and FDTtechnology. In this case DD Services are analogous to FDT frame applicationinterfaces defined in FDT specification and DDs+CFFs are analogous to DTMs.The technology used to implement the specification includes COM, ActiveXand XML. For example XML in FDT has nothing to do with the functionalityprovided by a DD which I call the business logics of deviceparameterization. So instead of comparing DD with XML you must compare DDwith 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 logicConditionals and logic are implemented in a DTM by using standardprogramming language (e.g. C++). As we know DD is not as powerful as nativecomputer programming language. In addition to that ActiveX providespowerful mechanism for GUI implementation lacking totally from DD language.So I would say DTM can handle complex devices but for simple devices it isoverkill.> - Is a proven technology that has been around for yearsExcept CFF. There are many hosts out there who still do not support thefinal 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 communicationprotocol 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 devicesinclude 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 andmaintenance of a device- Single FDT frame application can handle different field networksSome of the disadvantages of the FDT are:- Overkill for simple devices i.e. DD is more simple way to make deviceinterface and adequate enough- DTMs encapsulate the device data semantics and business logics (at themoment)Advantages and disadvantages depend on the viewpoint and the above listmixes them freely and is not as such useful for decision making.I believe both DD and FDT technology has a role in the automation withoutany impact to end user. The optimal solution would be taking the best outof both technologies.Kari HartikainenMetso Endress+Hauser Technology AG