[FUN] Field Device Tool - Device Type Manager

[Stephen Mitschke]

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 [SMTP:spragujl@aramco.com.sa]> Sent: Friday, November 16, 2001 11:11 PM> To: Verhappen, Ian> Subject: [FUN] Field Device Tool - Device Type Manager> > 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 setup> 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> E-2550 Engineering Building> Dhahran, 31311> Saudi Arabia> phone: 966-3-874-6414> fax: 966-3-873-0037>

[Stephen Mitschke]

> Ian,> > 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

[Stephen Mitschke]

> 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> relationships.> > 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.

[Stephen Mitschke]

> 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> FDT.> > John Halliday> Endress+Hauser Process Solutions

[Stephen Mitschke]

> Sean,> > 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.> > Regards> Kari Hartikainen> Endress & Hauser

[Stephen Mitschke]

> 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> handled.> > 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)

[Stephen Mitschke]

> 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 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...> > Regards,> Kurt> > 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