A unique—and free—document from the Fieldbus Foundation is its "AG-181 System Engineering Guidelines." Available for download from www.fieldbus.org, Version 2 had become outdated, as learning from early adopters revealed areas of unnecessary effort, complexity and expense. Over the past six months, experienced users, who've installed massive projects worldwide, have been gathering to give the guidelines a sentence-by-sentence overhaul. One of the unique characteristics of AG-181 is that it's written by users and for users, so it's by nature and by design a more vendor-neutral approach.
The new guidelines, which should be released in the first quarter of 2010, will feature some interesting departures from the previous revision.
Much of earlier editions was based on specifications developed for the first projects of early adopters in the late 1990s and early 2000s, which were understandably conservative. These projects didn't have many of the appliances available today, such as short-circuit protection for spurs, redundant segment power supplies/conditioners, redundant H1 interface cards or diagnostic tools for the fieldbus physical layer. Host accommodations for fieldbus were sometimes a "work in progress," so AG-181's original guidelines couldn't assume the reader was using the friendliest or most capable host system. The advances in host support, in particular the new registered host program, have made it possible to write the guidelines with greater confidence. If a host that's earned the foundation's "check mark" is used, novice end users won't find themselves in a pickle on account of assumptions made in the guide.
The new guidelines specify redundant H1 cards and redundant fieldbus power supplied for all spurs. This adds to the system I/O footprint noticeably, as well as increasing the average cost per segment, but consider the alternative. It's no trivial task to evaluate which segments contain only loops whose interruption would be relatively inconsequential, especially on a large project. One also has to consider future additions and expansions.
Would a segment with non-redundant H1 cards be chosen for a critical loop by the next project or expansion? If you're in a plant that goes years between shutdowns, flashing I/O cards with firmware upgrades on-line can become a big challenge when they're not redundant. True, a simplex H1 card architecture can be made manageable and reliable, but as segment count goes up, the cost of this effort outweighs the cost of redundancy.
The new revision also advises that one can dispense with "criticality ranking" for segment loading. The earlier guides set down a method for rating device/control valve/loop criticality, so very critical loops could be segregated from less consequential ones. Early adopters were concerned how interactions with non-critical devices—routine maintenance, additions, downloads, etc.—might affect critical loops. As projects became larger, this practice became increasingly burdensome, and users found ways to justify including or combining more loops of varying criticality on the same segment. Experienced users have concluded that the effort of classifying and segregating critical service loops is not worth the effort: There is minimal, if any, sacrifice of loop integrity or reliability when other non-critical devices or multiple critical loops reside on the same segment.
The older guides went to some lengths to address the counting and allocation of "virtual communication relationships" (VCRs), and reserved channels or "mailboxes" for data passed from device to device and device to host. Today's hosts have sufficient VCR capacity making this another engineering effort that's no longer important, so the new guide no longer encourages users to perform VCR calculations.
The draft guide will undergo routine reviews, editing and formatting this month. Watch the foundation website for announcements of the new release in coming months.
