This article was printed in CONTROL's July 2009 edition.
By John Rezabek, Contributing Editor
Foundation fieldbus (FF) has been around since the mid-'90s and fieldbus-capable hosts for nearly as long. For early adopters, there were few choices, so if you wanted digital integration of field devices using an open standard like FF, you rolled the dice with one of the one or two DCS vendors with real FF capability. New FF-capable hosts started coming into the market after Y2K, and some users suffered through bumpy beta-test-like years, as legacy hosts of the '90s attempted to adapt to the new open protocol. By last year, there were more than 15 hosts listed on the Foundation's "Compliant Host" web page.
"Compliant Host" came to be because users were seeking some objective way to evaluate the capabilities of various hosts. Do they support high-speed Ethernet (HSE)? Control in field devices? Function block instantiation? Can users download a "live” segment? How do users write a specification for themselves or their clients that ensures they get the features they want, but doesn't leave them with zero qualified bidders?
At first, the host DCS vendor community was not especially enthusiastic about any objective test; that's how the "Compliant Host" program came to be. It worked like this: a DCS vendor sends a list of its capabilities to the foundation; and the foundation then tests the host to verify that the features, in fact, manifest as described by the vendor. The Host Interoperability Support Test (HIST), unfortunately, produced a befuddling list of developer-level techie vernacular, which did little to reveal a host's advantages or deficiencies relative to another. In fact, it may have had the reverse effect.
So, users never stopped relying on their own wits, their peers' experience and vendor-specific test beds to reveal issues with features and interoperability before they, for example, 1) wrote their DCS specification, 2) made a purchase, 3) designed their plant's control system, and 4) started up/cut over to fieldbus.
The desire for an improved HIST has been on the FF End-User Advisory Council's "Top 10" for years, and it's taken years for the foundation and its members to finally approve a matrix of required capabilities against which all hosts would be tested. The "Registered Host" program has been developed as a remedy for end users who were dissatisfied with or mystified by the previous attempt at a host interoperability/compliant host test.
As of this writing, four hosts—ABB Automation Products' Industrial IT System 800xA, Emerson Process Management's DeltaV and AMS Suite: Intelligent Device Manager, and Yokogawa Electric Corp.'s Centum VP and Stardom—have already passed Phase 1 of the new registered host test, which highlights features most important to end users. By the end of 2010, a large number of features that were optional in Phase 1 of the new test will become mandatory.
One example is role-based diagnostics or FF's implementation of the NAMUR NE-107 standard. If you see it as essential for your next project (I would recommend it for anyone aiming to use the flood of new diagnostic information in an organized or standardized way), then require it in your specs. If enough of us do, we may spur our favorite host suppliers to rearrange their development priorities. Users can get a foundation-supplied datasheet/checklist, and select all the features they need to meet their digital integration goals.
End users can visit www.fieldbus.org, click on "End User Resources," and search the "registered products" catalog for "hosts." While the listings in the catalog don't delineate which features were mandatory for a checkmark in Phase 1, users can still compare competing vendors' features side-by-side with a little cut-and-paste into their favorite spreadsheet program.
The foundation has distinguished itself by integrating the priorities of its end-user community into its registration and testing processes. "Registered Host" will be a great model for similar digital integration technologies.