Up the interstate from us, one of our region's refineries is working on commissioning its first fieldbus project. The plant is adding a new gasoline feedstock upgrading unit, and decided it was time to start employing fieldbus. This site had done some pioneering work in the area of intelligent valve positioners, and its instrument department had been using that supplier's valve diagnostics and instrument asset management package since the 1990s. Unfortunately, said supplier doesn't make the plant's favorite DCS. So, with its first fieldbus system going in, it was faced with having to learn a second (and separate) asset management system, or creating its own kluge to integrate with the one created specifically for its legacy field devices.
With fieldbus, one has freedom to choose, but the world of open consensus standards—especially those that incorporate end-user input—can exhibit varying levels of achievement. Microprocessor-based devices should have a standard way to communicate with one another and with microprocessor-based hosts, and we're a long way down that road with all the leading technologies. But, users aiming to exploit recent innovations, such as NE107 field diagnostics, may have some concerns about how to craft their specifications. For example, you might be really enthusiastic about performing on-line valve diagnostics, only to be disappointed that either the positioners weren't purchased with the proper options or licenses, or that the host system's tools are missing some features you wanted. While a licensing oversight can usually be resolved by getting out your checkbook, it's still a significant effort to take a commissioned positioner—or any device—out of service to unlock the desired capabilities.
If you're aiming to do control in field devices, you'll find that positioners—the instrument that most likely performs device-based PID—are unequal when it comes to speed. The slowest can be six to 10 times slower than the fastest. The vast majority of loops, let's say 80% to 90%, are perfectly happy with dubiously synchronized, variable-latency, host-based PID. Normally, the project can get the plant commissioned and be out the door with 100% of loops solved in the host. It's as the plant matures, and the staff seeks out optimization opportunities, that the compromises made in the specification phase begin to surface. At that juncture, it's not unfeasible to replace positioners in a few applications. It's feasible, but not free or trivial. That the boss may be unhappy is not unfeasible either.
One solution is to hire a main instrument vendor (MIV) or main automation contractor (MAC). Before any specification or procurement for the project ensues, the controls lead gathers the key stakeholders—operations, maintenance, project management and systems specialists. This group then identifies a supplier who can be single point of accountability for everything from cabinet integration to orifice plates. Some track record of having done this for other clients is recommended, and I usually like a few end-user references I can call.
The MIV's role is meaningless if it has no resources or leverage to fix problems. And, since the DCS is perhaps the single biggest procurement line item and arguably the most proprietary and complex component of the process control package, it's hard to conceive of a case where the MIV is not also the host vendor.
But what about my neighbors to the north? When a brownfield site has a legacy installed base of incompatible DCS and asset management suppliers, there may be few options but to revert to the host's offerings. Be sure to get your arms around this during the "beauty contest" phase—it just might affect your host decision!
Evolving technologies such as EDDL, FDT-DTM and FDI may get us a measure of consistency between competing suppliers, but it remains to be seen how much this will extend to devices manufactured before 2010 or so. For all that remaining legacy installed base, some sites may have to keep their two-headed kluges alive.