Walter Driedger, chief engineer (process control) at Colt Engineering in Calgary, Alberta, advise novices that “choosing a distributed control system (DCS) is like choosing a mate.” The fidelity of operators and engineers to their familiar companion may defeat any attempt to upgrade or modernize, or the infatuation of honeymoons in Phoenix, Austin or Foxborough wear off, and the pain, cost and complexity of switching to another supplier may make an end user feel trapped. Workers on projects that install a new DCS in place of a beloved old one get to hear about all the things the old one did better.
With control capabilities now ubiquitous in Foundation fieldbus devices, you could say Foundation fieldbus is a “vendor-neutral DCS.” While Fieldbus Foundation doesn’t test the inner workings of every PID block, the basic functionality and “hooks” that integrate each block with the rest of the system are certified for “interoperability.” If you allow yourself an eclectic selection of devices, you can do everything from simple PID and cascade loops to split-range and cross-limiting (constraint) control. One application in our plant does “anti-surge” control—albeit of a blower—entirely using one vendor’s repertoire of device-resident blocks.
So does this mean end users can now flit about blithely from one host DCS supplier to another? Do we even need a DCS anymore?
Some early adopter visionaries dreamt of this, and one implementation of Foundation fieldbus technology by Smar could indeed be said to be a “no DCS” solution. When employing control in the field, even a “DCS lite,” such as Smar’s, where the host can function almost exclusively as operator interface and engineering/configuration tool, is still a “distributed control system,” where the “control” part is distributed to field devices. To be fair, Smar packs some additional processing power in HSE devices that strongly resemble a traditional DCS or PLC “controller.”
If a great majority of loops are distributed to field-solved PID, what are the chances you could “hot swap” your host, like we do field devices? Employing a backup “link active scheduler” keeps loops functioning when the wires are removed from the DCS host. Can you just land them on your new DCS and expect all to proceed swimmingly?
Not likely. While every fieldbus host has an engineering tool to configure the same standard blocks in fieldbus devices, every block isn’t supported by every host. The “saved” configuration of your old system is not portable to another. The blocks, parameters and interconnections are “standard,” but the way these are represented and compiled is vendor-specific. Each host’s link master has a slightly different procedure for addressing and commissioning devices. Chances are every scheme will have to be re-engineered individually; each segment will have to be re-commissioned; and every block and device taken off line for some time.
That said, it’s conceivable that any field-based control could be precisely replicated using hard-copy printouts, again assuming the “new” host supported all the blocks the old one did. So a field-based control strategy, while not portable in the sense of Java or XML, still could be “standardized” for a more consistent and expedient application across multiple hosts.
Any host-resident control, on the other hand, would require a significantly more thoughtful, slow and expensive effort. The “rest” of the functions performed by the host—operator interface, diagnostics presentation, historians, etc.—still vary as much as ever. Like FDT-DTM? Not every host can do it. Do you think “device alerts,” where devices proactively “push” important diagnostic messages to the host, are essential to getting the value from your fieldbus investment? I only know of one host that supports it.
Switching your DCS will remain as complex as ever, so Driedger’s advice is still well worth heeding. If you still want to flit about, better don your armor and get out your wallet.
