Voices: Rezabek

A Logical Path to Device Criticality

If You're Aiming to Improve the Usefulness of Your Digitally Integrated Intelligent Field Devices, There's Help Available to Help You Get Moving Down This Road

This article was printed in CONTROL's December 2009 edition.

John RezabekBy John Rezabek, Contributing Editor

Ten years ago, early adopters concerned about the real reliability of fieldbus technology devised guidelines for device criticality to optimize segment loading. In detailed design, the process control team assessed the potential of each device to cause an untimely process interruption. Those that would immediately shut down the process were assigned the highest criticality, and those whose failure would be relatively inconsequential, the lowest. The critical devices were segregated on lightly loaded segments and H1 interface cards, and those with low criticality were loaded on segments to the maximum practical number, with considerations for physical device location and function. The total number of control valves on critical segments was set as low as one. So we felt better, at least, that we would have less risk manipulating or maintaining a non-critical device and having an adverse impact on a critical control loop.

Experience has borne out, however, that H1 is so reliable that some users now load all segments more or less equally (e.g., aiming for 12 devices per segment). Transmitters and valves from non-critical services are combined on segments with the most critical ones, assuming the practical matters of proximity make it worthwhile. The latest draft of the Fieldbus Foundation AG-181 systems engineering guide has incorporated this as a recommended practice.

Criticality ranking may have some use, however, for getting the best value from device diagnostics. As instruments and systems are released that support NAMUR NE107 diagnostic alarm prioritization and routing, we're seeking a method for determining which device alarms get enabled and given a high priority. For example, setting the alerts for low instrument air supply on every valve positioner sounds like a great idea, until the night the whole header slumps, and your operator has to deal with potentially hundreds of redundant alerts. Some experienced practitioners are using the old criticality rankings to devise alerts, and pare the potentially vast number of device diagnostics down to the few that may be of real value.

For most reliability-focused users, the task of actually doing this ranking is a little daunting. It can prove challenging to assemble the right resources and people to devote their time to it. So, some consultants have appeared to help us.

For example, I have found the PlantWeb Services division of Emerson Process Management useful. I think users will find its methodology for arriving at a "maintenance priority index" (MPI) compellingly logical.

To rank a device, begin by dividing the plant into functional systems, for example, "steam system" or "boiler 1." Apply such metrics as the system's impact on safety, environmental compliance, product quality and throughput to get a "system criticality ranking." So, for example, one determines that boiler 1, which has no spare, has a relatively high system criticality compared to the instrument air system fed by redundant compressors.

Next, operations specialists assess the importance of the assets that enable them to keep the system on-line, in effect asking, "If I lose this, what will be the effect on the process?" So, in the case of the boiler, operations may assign a high "operational criticality ranking" (OCR) to boiler feedwater pumps or steam drum level instruments.

Following the derivation of OCR, the asset's "failure probability factor" is applied, which I'd read as "mean time to fail." So, an unreliable level instrument on the critical boiler will end up with the highest MPI. Such community-derived prioritization has some side benefits, among them the mutual acknowledgement of maintenance that can be deferred to planned maintenance.

If you're aiming to improve the usefulness of your digitally integrated intelligent field devices, there's help available to help you get moving down this road. Getting it right can make a measureable difference in the effectiveness of your maintenance efforts. 

More from this voice


Easy Oscilloscopes for All Buses

Troubleshooting Fieldbus Is Rarely Straightforward. One Might Need to Disconnect Segments and Shoot Them With Oscilloscopes and Meters


Everyone, Do Your Own Math

The Incremental Costs to Add Spurs to These Fieldbus Segments make WirelessHART at Best a Break-Even Option in Many Circumstances


Failed Bus Blame Game

If You Allow Yourself to Be Dour, Defeated and Critical of Your Selected System, You Could Be Headed for Disaster


Fieldbus Flavor of the Month

We May Be Missing Real Innovation in Our Field. Lets Adopt the Latest Controls or Instrument or Network Technology Flavor


Fieldbus Savings the Same in Dollars or Yuan

There's Been Too Much Hype About the Cost Savings of Fieldbus. The Same Thing Can Be Done With Remote I/O


Fieldbus for Safety Instrumented Functions

FF-SIF Transcends the Limitations of Conventional Safety System Design by Introducing New and Innovative Ways of Thinking About Safety


Fieldbus is Dead! Long Live Fieldbus!

The Competing Communications Technology That Presumably Will Replace All These Buses, Including Process Fieldbuses, Is Ethernet


Fieldbus on a Shoestring

Use the Wire You Have. Unless You’re Really Challenging the Limits of the Physical Layer, Ordinary Twisted/Shielded Pair Will Work Reliably


Fieldbus-Where's the Love?

How Does Fieldbus Bring Flux and Uncertainty Where There Used to Be Order?


Fieldbus: Do Fence Me In!

Just Because You Can Put 12 Devices on Each Fieldbus Segment, Doesn't Mean You Should


Fieldbus: Lion or Lamb?

Ways Fieldbus End Users Can Avoid Increasing Stress for Their EPC Consulting Firm


Finally, Registered Hosts

"Compliant Host" Came to Be Because Users Were Seeking Objective Ways to Evaluate Different Hosts's Capabilities


Finding Freebies in Fieldbus

Can We Use the Standard Deviation Method to Flag a Suspicious Measurement?


Foolproof Fieldbus II

Sometimes Our Well-Intentioned Attempts to Make a System "Foolproof" Create as Many Hazards as We Were Aiming to Prevent


Forays into Fieldbus Technology Pay Off

Plenty of Training Resources Available to Get Team On Board


How Can Incompatible DCS and Asset Management Suppliers Get Along?

One Throat to Choke: When a Site Has an Installed Base of Incompatible DCS and Asset Management Suppliers, It May Have to Revert to the Host's Offerings


How's Your Fieldbus Resume?

What Kind of Qualifications Should You Be Displaying to Qualify for the Jobs That Are Available?


Hungry for Open Network Protocol Standards

You Just Can't Be Apple to Your Customer and Control Every Widget You Sell


Instrinsic Safety Obsolete Yet?

Like Most End Users, I Truly Value the Credibility and Security That Organizations Such as Factory Mutual, the Canadian Standards Association, CENELEC and Their Ilk Bring to the Devices We Use in Hazardous Environments. But Perhaps One Practice is Ready to Be Relegated to the ISA Museum of How We Used to Do Things. Here’s Why.


Is Field-Based Control More Secure?

If We Hide Our Controls in Field Devices, Are We More Immune From the Infections of the Higher-Level Networks?