Foundation Fieldbus / Fieldbus

Is Fieldbus worth it?

Successfully implementing and supporting Foundation Fieldbus requires changes in how projects are engineered

As the guy from the refinery up the interstate from his facility, who is most responsible for bringing in Foundation fieldbus (FF), let me weigh in on John Rezabek’s “Is fieldbus dead?” and the responses to it.

Is Fieldbus better than 4-20 mA instrumentation? Yes. Is it harder to install and maintain than 4-20 ma instrumentation? Fieldbus is not hard, but it is different.

The impediments to wider adoption of Fieldbus (or any digital technology) are:

  • Vision: what do you want to do beyond what you're doing now?
  • Engineering: implementing FF is different from implementing 4-20 mA.
  • Culture: new technology necessarily changes workflows, job responsibilities, and skill sets.

In our case, adoption of FF was part of a bigger vision I like to call “getting rid of sneaker nets.” In our refinery, if it can communicate, it’s on a network: motor control centers, analyzers, compressor diagnostics, vibration monitors, heat trace panels, as well as the remaining HART instruments (primarily SIS). We recognize that while operators are our most important customers, maintenance is right behind. The old model of having common alarms to the process operator never worked. Now, that data often goes directly to the people who can do something about it.

When we did our first FF project in 2005, we assumed that FF instruments were just like conventional instruments, and we could do the project just like any instrumentation project. By the time we realized FF really is different, it was too late to change our approach, and we were not happy with the results. This was followed by vows of “never again.”

So, they questioned my sanity for using FF again on an even bigger project (“Foundation for expansion”).

As to culture (for lack of a better word), new technology necessarily changes how we do things. Successfully implementing and supporting FF requires changes in how projects are engineered, how the DCS is programmed, and who is responsible for maintenance activities, procedures and training.

For example, consider changing the range on an instrument. On conventional instruments, this requires a trip to the field and possibly some scaffolding or a lift if the instrument is inaccessible. Operations will know this work is going on because there will be a permit written. The planners and schedulers have a script to follow to plan and schedule the job. How to do this has been established for years, it's written in everyone’s procedures, and everyone is trained—it’s a non-event.

With FF (or wireless or HART), the control engineer, instrument engineer or technician can make this change from his desk. Now we have a problem. Who is responsible for this work? Does this job have to be planned? Is a permit required? How do we notify operators that this is going on? How do we program the DCS, so that if (heaven forbid) the transmitter range is changed while the control is still in automatic, we don’t have a process upset?

With FF we can change a four-hour job involving perhaps six people into a five-minute job, but it takes a lot of work changing the training, procedures and attitudes to get there.

To me, it’s worth the effort.

Ed Bullerdiek