MY QUESTION is about pre-testing Foundation fieldbus instruments. I’m a commissioning engineer on a large, greenfield project where we’ll be installing more than 8,000 instruments, 25% conventional and 75% “smart” devices. Is there any recommended pre-bench testing of these smart type devices? If so, what type of testing and for what type of instrumentation? There’s so much literature on this subject that I’d rather ask the experts directly.
Thank you, Robert and Jonas, for your prompt replies earlier on this matter. We here in commissioning management agree full heartedly with you both. We’re aware of the Foundation fieldbus certifications, and aren’t overly concerned on compatibilities within the different host systems.
Our primary concern is mostly insuring that the instruments haven’t been damaged internally or externally during shipping. The project is in South America, and obviously a large quantity of the instrumentation equipment will have been subjected to various handling and lengthy transportation requirements. This project includes several processes, and we wish to minimize any delays due to any unforeseen pre-testing that may prevent such cases. Are there any statistics on initial failures due to such damage?
Again, this project is large-scale and in the early construction phases without any instrumentation actually being mounted yet. We should have time to develop further protocols to insure that we comply with all or some of the recommendations.
Manuel J. Gortarez, Senior Commissioning Engineer,
Sulphide Leach Project, BHP Billiton
Set Software Tag, Check Calibration on the Bench
I’m not really sure how you define "conventional" and "smart" devices. I think the most common definition is:
conventional = pure analog 4-20 mA;
smart = 4-20 mA analog with superimposed simultaneous digital communication, such as HART; and
fieldbus = pure digital communications, such as Foundation fieldbus H1 and Profibus PA, though some also count HART here.
It appears you’re referring to HART as conventional and Foundation fieldbus (FF) as smart. Anyway, for HART, Foundation fieldbus, or Profibus PA, I would set the software tag, and check the calibration (trim) on the bench for any device regardless of protocol. That is, apply input, and correct the reading if it’s wrong. Remotely, you can only do re-range and other parameterization. Re-range is not the same as trim.
These days, don't worry so much about pre-configuring the range, square root, and damping because these can be configured remotely. Most new control systems have device management software that effortlessly compares the actual device configuration against what is should be according to the database, and allows you to reconcile the differences.
To become fully operational, FF devices need a configuration download of blocks, links, and schedule, which is best done when the device sits on the system where it will operate. For commissioning, parameterization, and management of fieldbus instruments, take a look at Chapters 3, 4, and 9, respectively, of the yellow book, “Fieldbuses for Process Control: Engineering, Operation, and Maintenance.”
In addition, the difference in hardware between devices using HART, Foundation fieldbus, or Profibus PA isn’t very big. The HART device has a different communication chip and less memory. The big difference is in the software. Transmitters for either protocol use the same sensors, and valve positioners use the same output transducer. Therefore, we haven’t noticed any difference in failures of either protocol. They’re very much the same device.
Jonas Berge, Smar
Certifications, Device Testing Aid Familiarity
The Fieldbus Foundation does a device certification on all devices before they can be listed as Foundation Fieldbus-certified devices. For any device that has gone through this certification, a check mark should be located on the tag that is placed on the device when it’s manufactured. The device will also show up on the Fieldbus Foundation’s website.
Many host-system suppliers also have implemented a device-testing policy. These tests are more specific to the particular host system. In both cases, testing/certification is meant to insure that devices are interoperable between host systems and different device manufacturers.
As far as pre-bench testing is concerned, I normally recommend to customers that they configure a variety of the devices that they plan to implement in a lab environment prior to integration of the devices in the field. This gives users:
More familiarity with FF technology and the host system they’re using.
More familiarity with the various devices they’re integrating into the host system.
Assurance that all the proper wiring, power supply, and other miscellaneous components needed for communications are present. If problems are found, they can be corrected prior to installing the equipment in the field.
Confirmation that customers have the proper device drivers needed for their installation.
On large jobs such as the one described here, it won’t be possible to hook up all of the devices in a lab environment. I would suggest that at least one of each different manufacturer's devices be present for the pre-installation testing. In most cases, manufacturers share FF technology in their R&D facilities, so hooking up one device from the manufacturer will help users understand any differences from that manufacturer’s implementation to others.
Robert Lagrange, Business Manager, Water and Wastewater, Endress+Hauser