EDDL real capabities

[Hamad_1974]

Hello all,

Could someone tell me if EDDL can be used to perform more advanced features with instruments such as generating valve signatures?

I was under the impression that EDDL, like FDT/DTM, would allow the user to tap into a manufacturer's field device and perform valve signatures and others and not just read or display the existing data. Anyone would like to comment?

We're in the middle of installing control valves fitted to Fisher's DVC's and I really would not like to see properitory plug-ins to tap into the ValveLink software. Has anyone experienced this before?

Thank you

[rezabejd]

. . .
Could someone tell me if EDDL can be used to perform more advanced features with instruments such as generating valve signatures? . . .

Yes - EDDL can be used to perform valve signatures. I have used it on Metso ND9000 positioners, and their EDDL supports step tests. See attached - this is not even the more graphics-intense "enhanced" version - for some reason DeltaV 10.3 doesn't support it yet.

No - not so far with DVC's. You still have to use Valvelink, but work is progressing well on FDI which will incorporate the Valvelink-like (FDT-DTM-like) capabilities into a standard interface. See article here . . . (http://www.controlglobal.com/multimedia/2010/GK_Agreement1001.html)

[Hamad_1974]

John,

Thank you for the FDI link. It is really informative. DO you know if Fisher is going to allow their valvelink to be accessed via EDDL in the future )or even through FDI)? Doesn't this threaten their AMS legacy?

We the end users do not like the so called plug-ins and properitory solutions.

Thanks

[rezabejd]

. . . DO you know if Fisher is going to allow their valvelink to be accessed via EDDL in the future )or even through FDI)? Doesn't this threaten their AMS legacy?

We the end users do not like the so called plug-ins and properitory solutions.

. . .
We are working to get the user's voice heard, and it doesn't hurt when we vote with our $$ . Certainly Emerson's competitors feel their opposition to FDT-DTM was due to its weakening of AMS's marketing position. However when a big job essentially said, "create DTM's to work with our (non-Emerson) host or we will get our valves elsewhere" I think the work got done.

Whatever is ultimately accessed through FDI will not likely be full-blown ValveLink, but it may ultimately be the more attractive solution, mostly on account of security, I think. True "Asset Management" means you don't have undocumented changes being made, mechanisms for management of change are enforced, and no one accesses devices without some substantial login rights, among other things. You will get this, as I understand it, with EDDL and FDI.

[ccarter]

John,

In your comments about security, will EDDL and/or FDI going include anything that will ensure someone cannot accesses a device, or make a change in a device with a hand-held communicator or external laptop? Or will this still require hopefully adhered-to MOC procedures?

I regularily update our Fieldbus courses to include the latest in EDDL/FDI/DTM..LSMFT, etc. and would hate to mislead folks into thinking that they will prevent any chance of someone breaching security, whether accidently or on purpose if that is not the case. The short part of the story, is that I have demonstrated (even in EDDL devices) that today a person can make a key change on a device with a portable host. Note the change may be alluded to inside a particular asset program (such as seeing a "field change" inside a audit trail), but not all asset programs can do even that.

Thanks,

Chuck Carter
Center Director
The Fieldbus Center at Lee College

[rezabejd]

Chuck, your point is well taken and I agree, even e-EDDL devices and the systems that support them have security holes. For example, 475 communicators come eEDDL capable but have no special provisions for login, so far as I'm aware.

If you DON'T have rigorous procedures for management of change or question your ability to enforce them, I would simply NOT HAVE handheld devices and / or laptops for device configuration, or at a minimum forbid their use in the live plant. Then all configuration happens through the host and at least requires a priveledged logon, along with a good chance of recording who logged on when and did what. FDT-DTM to my knowledge is quite independent of the host; FDI will be less so, but like other FF technologies their will still be features that will rely on the host developers to deliver them. Customers may have to clamor for it to get their favorite supplier to devote the needed resources to get it implemented.

[ccarter]

Thanks for the clarification, John.

The good news is I have found that once I teach (techs in particular) about the dangers of "playing around" inside a fieldbus devices with a handheld, etc., they totally accept the need to have a solid MOC procedure in place. The down side mostly envolves a semi-trained or non-trained person getting on a device. Of course that person can also do a lot of damage if allowed to enter a host program. So we all spend time during the courses discussing logons, passwords, and the like, again with great success with the techs. I am convinced that good techs want to add value to their fieldbus and do such things the right way. Maybe we just need to get the word out.

In the meantime, I have been working on a means for using the STAT_REV counter in a practical way for flagging field changes, but not much luck yet. I sure would be nice if the block could point to which parameter was changed last. Nothing new there, but as I look at it from the user's perspective and not the beenie copter's, some obvious uses come up and others just won't work.

Thanks again,

Chuck
Chuck

[WHodson]

I have been suggesting for many years that Fieldbus security weaknesses should be addressed. It has not been a high priority. Users need to prioritize this to the Foundation through the User Advisory Councils.

Currently a Fieldbus device will respond to any “host” that writes to it. The original expectation was that there was only one host (a DCS) and it provided any authorization security that was really needed. But with handhelds, asset managing hosts, and DTMs (programs written by device vendors who may not know what they should not “touch” in a DCS-configured device), the potential for inadvertent changes or even deliberate misdoings should be addressed.

A potential solution is to provide multiple host management connections at the device, one for each type of host (operating, configuring, field access, asset managing), and only allow certain view access and change access thorough each connection. The connections could be configured to enforce plant management’s policies regarding access.

Bill Hodson
Hodson Consulting, LLC

[ccarter]

Bill, this could be a completely new thread, but I will test the waters to that end with these comments.

I have commented many times that we may be trying to apply legacy thinking to a new technology in regard to work practices and that just won't work. Security is one of the areas where a little legacy thinking may actually help define what could and should be done. Security of settings, operation, etc. is not a new item that fieldbus brings to the table. It has been an issue for years and I think for the most part has been successfully managed. Fieldbus just adds an order of magnitude to the issue.
I am concerned that trying to build a totally secure system could actually be counterproductive. It could lull people into thinking "this could never happen" when in fact it might be possible. Rather, I would like to see companies do the same as occured when the same potential for causing problems with, for example, HART device configuration and setting reared its ugly head in the early days of that technology. Get folks trained and you may not have to spend as much in building a "foolproof" system. In the olden days of legacy technology, remember, a tech with a HHC could easily cause operators to experience more than a little gnashing of teeth and grunting of various body parts if he or she messed up any of a myriad of settings or calibration values, to cite just a couple of examples. Training and experience have proven to be clear mitigating factors and I would like to know what is so special about Fieldbus that the same cannot be true for it.

Just a thought to ponder.

[rezabejd]

. . . Get folks trained and you may not have to spend as much in building a "foolproof" system. . . .

Just a thought to ponder.

From our IT friends, "If you make it foolproof, they'll build a better fool" (unknown).

And from Mordac, preventer of information services:
(attachment) (http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/00000/1000/700/1781/1781.strip.zoom.gif)

[jberge]

Like John illustrated, EDDL can do all the advanced features

See also this white paper
http://www.eddl.org/SiteCollectionDocuments/TechPapers/wp_EDDL%20device%20diagnostics.pdf

EDDL, FDT/DTM, and FDI have nothing to do with connecting portable hosts. All make it possible. This is a unique capability of FF (and HART) not found in other bus technologies, which is highly valued by many users. Security to disable this capability would require a change to the protocol. FF-SIF has this capability I believe. It is along the same line as making changes from a local display. EDDL, FDT/DTM, and FDI will not stop that. Some users argue for the use of portables as they find it handy. Some of the reasons why technicians like portables are in this white paper:
http://www.eddl.org/SiteCollectionDocuments/wp_EDDL%20field.pdf

You could always lock up your handhelds and laptops :-) But depending on the device somebody could use the local display

John is right. It does not matter if you use EDDL, FDT/DTM, or FDI. If the computer does not have a secret passwords, anybody can make a change. Many times the password is written on the laptop cover...