An engineer once suggested that selecting a DCS was like getting married—the relationship with your DCS is not one you'll ever end lightly. If you experience "buyer's remorse" down the road, the cost and complexity in ripping out one host and installing a new one is nearly always prohibitive. Before making your choice, you can feel like a contestant on "The Bachelor" or "Bachelorette" in the throes of courtship. Like the Bachelorette, you'd best remain sober, objective, ask a lot of the right questions, and be on the lookout for red flags before jumping in bed.
The decision matrix from Kepner-Tregoe (KT) and similar methodologies are large and complicated, as many stakeholders are going to share in the joy—and pain—of the choice you make. Hard as we try, the weightings and ratings we give competing systems can become more emotional than rational. When we narrow the field, we hope it's not who took us on the best date that gets the "rose."
If I'm on your team, I'll insist that fieldbus capability is not only a "must" in the KT sense, but also deserving of a "weighting" based on specific capabilities. Why? Because a system that doesn't readily accommodate digital integration of field devices using a standard protocol, such as Profibus or Foundation fieldbus, is destined to be obsolete the day it's powered up.
"Intelligent" or "smart" field devices have been around for over 25 years, and from the beginning engineers have thought that a standard akin to 4-20 mA was required for communications between host DCSs and devices. This is why Foundation fieldbus (FF), Profibus and the other technologies in IEC-61158 exist—because users insisted on it.
[pullquote]I'm a "shameless" supporter of fieldbus because FF and Profibus were standards end users wanted—not a proprietary technology. Foundation fieldbus has been adapting and changing for over a decade in response to the demands and desires of end-users; HART and Profibus, partners in EDDL and other improvements, have been quick to provide parallel capabilities.
One of the things FF end users demanded is standardized, meaningful host (DCS) testing. Today over a dozen host systems have undergone testing by the Fieldbus Foundation. The foundation has created a variety of "host profiles" that delineate the most important attributes any fieldbus host should possess. If you obtain copy of the current FF Systems Engineering Guide (AG-181 revision 3.1 or higher)—a free download from fieldbus.org—you'll find an entire section devoted to host specification and selection.
You will get not only free guidance on host selection from a diverse committee of long-time FF end users, but also the definition of FF's host profiles. "Class 61" is for "integrated hosts" Because hosts have been on differing levels of achievement, the progression of capabilities is gradual. The first level of capabilities is "61a" and specific services, such as Foundation device description support, that are mandatory for an FF "checkmark."
More capabilities are mandatory for "61b" certification, but many remain "optional." End users can use these capability descriptions to ensure their selected host will support the specific capabilities they require, whether optional or mandatory. Non FF users might use the list as a guide to what questions they should be asking their suppliers.
So, would it be a "must" that my projects' host possess an FF checkmark? I would go even further and require the more advanced 61b, which makes support for NAMUR role-based alerts and diagnostics "mandatory." As of now, only two systems, Emerson's DeltaV and GE's Control ST for the Mark VIe Control Platform, have received a checkmark for 61b, but more are certain to follow.
The guidance provided in AG-181 and the documentation of tested, registered host capabilities is free to everyone with Internet access. I'd encourage everyone to make use of them before selecting your "mate."
