Is fieldbus dead?

Settling for less is fine for the simple minded and poorly led.

By John Rezabek

Why did I talk my wife into an Android smart phone? All her sisters and her daughters have iPhones, and the famous IOS and Apple networks facilitate easy sharing of pictures and videos among iPhones and i-everything else. It seemed like a good idea—she liked using a stylus, as the tiny screen of her old iPhone 4 was not very responsive to her touch. So a big-screen Samsung Note with a built-in stylus seemed like a good choice. But even after a couple years of continuous use, her aggravation with the incompatibility between the operating systems and networks continues. You can imagine my dismay at having made the recommendation, and reluctance to ever proffer advice on the matter again.

Some have experienced a similar sentiment when it comes to fieldbus technology. In our zeal to seize the new digital day, we have created unintended pain and frustration for our end users. Not that long ago, the many paths to the “trough of despair” following adoption of this revolutionary technology seemed to overshadow the numerous benefits of digitally integrated field devices on a two-wire bus. Lacking the leadership to learn from the mistakes of the early adopters, the ensuing flight back to yesteryear’s technologies has continued unabated for projects in many world regions.

The mistakes of those early adopters were rudimentary and have been well documented, as have the best practices that help ensure success. Still, fieldbus—an imaginative and robust solution for efficient deployment of a 100% digital measurement and control system—continues to be underutilized. It has become so under-marketed compared to wireless, some end users have been asking me: Is fieldbus dead?

In a recent blog post, Emerson’s Dale Perry does a reasonable job of comparing fieldbus technology choices. While recounting many of the better attributes of fieldbus (both PA and Foundation), the concluding recommendation is we’re better off deploying HART and WirelessHART, which is perhaps a foregone conclusion considering the author’s place of employment (the inventors and chief proponents of all things HART). I’d contend Dale’s conclusion is correct if you include the following qualification: A blend of HART and WirelessHART is often the best choice if one lacks any energy, desire or acumen to deploy the superior solution for process control, which is Foundation fieldbus. As it is so often the case that this energy and desire are lacking in projects, the recommendation is hard to dispute. It’s unfair to vilify Dale for taking the position he does, since no vendor, not even the great and powerful, is wise to confront their paying customers with an unflattering truth.

It’s unfair to vilify Dale for taking the position he does, since no vendor, not even the great and powerful, is wise to confront their paying customers with an unflattering truth.

I wouldn’t dispute the contention that wireless infrastructure should have a prominent role in any process plant environment. My experience with WirelessHART measurements supports the assertion that it’s sufficiently robust for many closed-loop control solutions. But control valves have challenges: Wireless is not a slam-dunk since our paradigm for valve fail positions requires a continuously powered pneumatic transducer (I/P) to oppose a powerful spring. There will be wires for decades to come. If you can wrest yourself from 4-20 mA, the same copper pair that powers your control valve can provide power and deterministic digital integration for dozens of other useful measurements, including the PV that you’re aiming to control.

Smart digital devices and digital hosts should interconnect digitally. If you’re an end user or consultant who comprehends the intrinsic value and logic of this concept, delivered by fieldbus and wireless, don’t be dismayed by flaccid vendor marketing. Like converting an iPhone diehard to Android, you will be well served to engage all likely stakeholders—designers, installers, commissioning teams, operators and maintainers—and enlighten them about how their experience will be different, and how to make the best of it. Experienced end users have documented recommendations and best practices for simple and efficient project execution, and the ISA 108 committee is codifying the key practices to exploit device intelligence at all points in the process plant lifecycle. Successful and prosperous fieldbus projects are not outliers.

Fieldbus is often the least expensive installed cost, assuming one’s host supports both wireless and fieldbus. Since this contradicts the post, next month we’ll do the math.

Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


  • "Settling for less is fine for the simple minded and poorly led." - John Rezabek John, I have to disagree with your premise. In the real world you quickly find that Fieldbus requires a level of technical acumen that is far above that needed to maintain a 4-20 mA loop. We have a hard enough time staffing vacancies as it is. Introducing Fieldbus into the mix simply compounds the problem by expanding the minimum skill sets required to do the job. By necessity we design for the lowest common denominator, but those designs are bulletproof, low tech, and robust. I once heard an integrator state that "Fieldbus was a solution in search of a problem." I wouldn't go that far, but I fully understand his sentiment. I have yet to encounter a control problem of any kind where I ended up saying "If only we had Fieldbus." Rant all you like, but the overwhelming vote of the end users regarding Fieldbus seems to be "thank you, but no."


  • Thanks for the feedback . . . agree the tagline is harsh and the "voters" in North America have expressed a desire to stick with 4-20 mA. That was sort of the point. I am a long time end user of fieldbus serving a well managed process plant - I'm not in a lab or a school - and I would not do a project that didn't fully utilize it. I know numerous end users working for major oil companies and their ilk that feel the same. The refinery up the interstate from me completed a 1 billion plus heavy oil / coker upgrade a few years ago - primarily FF - and they draw from the same labor pool as the rest of us in the Midwest. So it isn't a "solution in search of a problem". I don't know - should we be happy or satisfied that we default to technology of the phone modem because we don't develop or train people capable of better? I acknowledge that our national corporate obsession with "doing more with less" (people) is a big contributor to our culture's reluctance to venture far from the comfort of yesterday's solutions . . . I don't blame anyone for doing so - we have to choose our battles. But I would encourage anyone inspired to utilize an equally robust and vastly more capable solution to do so - don't tie the next generation to the solutions of yesteryear. Best Regards, John


  • John, thank you for your reply to my comments. I now have a better understanding of where our respective outlooks are coming from. We are looking at the same situation through two very different lenses. I work for a small mining/metal producing facility with definite boom/bust cycles and occasionally thin operating margins. The overall organization is very flat and our headcount is deliberately kept lean. Under those conditions we do not have the option of hiring E&I employees with significant experience. We bring in people fresh out of school and then train them on site. Within 5-7 years they become very effective - and then they leave. We are located in close proximity to a number of refineries. Refineries tend to print money, have large operating budgets, and can afford to pay top dollar for the best of the best. They only hire experienced people, and they are almost certain to hold onto those people for the rest of their career. For a refinery it makes sense to expend the time and effort to develop their people to the very pinnacle of the technology. They have the budget, numbers, time, and technical acumen to ensure that a Fieldbus solution will succeed. For us the situation is very different. Our daily task is keeping the lights on using a small number of predominately rookie employees. Those that have been trained and are fully effective cannot be counted on to stick around, Greener pastures beckon, and they will leave. We deliberately avoid Fieldbus because we know that we do not have (and will not have) the human infrastructure to maintain it. The solutions we implement may not be as high tech as a state-of-the-art Fieldbus installation, but they do everything we need them to, and when they break our people have the skills to fix them quickly. I suspect that our situation is more in common with most enterprises across the US than yours is. Those sitting on top of the heap look at those on the bottom and wonder why we don't join them. What they don't realize is just how unique their situations are. For the rest of us joining the top dog isn't really a viable option. When a pinnacle installation like a refinery berates the rest of us for not joining them in the Fieldbus revolution, they don't seem to realize that they are very much like Marie Antoinette exclaiming "Let them eat cake!" Fieldbus isn't dead . . . but for most of us it just isn't a good fit.


  • As the guy from the refinery up the interstate from John’s facility that is most responsible for bringing Foundation Fieldbus to the refinery let me weigh in on John’s “Is Fieldbus Dead?” column and the responses thereto. Is Fieldbus better than 4-20 ma instrumentation? Yes. Is Fieldbus harder to install and maintain than 4-20 ma instrumentation? Fieldbus is not hard, but it is different. Moving to Fieldbus from 4-20 ma instrumentation is like moving from a rotary phone (for those who may still remember what those are) to a smart phone. The reason you buy a smart phone is you want to do more than just place calls from your house. Getting additional value from a smart phone requires doing some work. It also changes how you interact with the phone. If you are happy with the rotary phone there is no reason to change. The impediments to wider adoption of Fieldbus (or any digital technology) are: • Vision: What do you want to do beyond what you are doing now? • Engineering: Implementing FF is different from implementing 4-20 ma instrumentation. • Culture: New technology necessarily changes workflows, job responsibilities, and skill sets. Vision: In our case the 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 the remaining HART instruments (primarily SIS). We have come to recognize that while process operators are our most important customers the maintenance organization is right behind. The old model of having common alarms to the process operator never worked – now that data goes directly to the people who can do something about it. (This is still a work in progress.) Engineering: When we did our first FF project in 2005 we assumed that FF instruments are 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 in the project to change our approach. We were not happy with the results, and based on my conversations with peers a great many early FF projects were also done the same way with the same lackluster results. This was followed by vows of ‘never again’ and then they questioned my sanity for using FF again on an even bigger project. (Self-promotion alert: Please see my article in Control for an overview on execution. This was written because there appeared to be a need.) Culture (for lack of a better word): New technology necessarily changes how we do things. Certainly the smart phone has changed how we live. Successfully implementing and supporting FF requires changes in how projects are engineered, how the DCS is programmed, who is responsible for maintenance activities, procedures, and training. As an example consider changing the range on an instrument. On conventional instruments this requires a trip to the field by an instrument technician 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 before the tech can go into the field. 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 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 the 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 6 people into a 5 minute job, but it takes a lot of work changing the training, procedures, and attitudes to get there. I understand where Mr. Davis is coming from. FF isn’t difficult, but there is a lot to learn and do to make it successful. It is not unreasonable to look at your organizations resources and goals and conclude that, at least for now, FF is not for me. I also understand John’s frustration. He works in a smaller chemical facility (not a refinery) that has gone through the learning curve and sees the benefits of FF. As an advocate his challenge to industry is ‘why not?’ As for me, I would much rather work with FF. Projects go much faster during the critical phases and have fewer problems if done correctly. But there is more upfront planning required and, at least based on my experience, the EPC’s, DCS vendors, and process technology licensors just don’t get it. They will by default follow approaches designed for pneumatic instrumentation (yes – really) which cannot unlock the value of digital technology. So John’s criticism is not wrong. The usual players cannot get you there. The onus is on the client to lead the team through the process, which requires an automation lead with the energy, desire, and acumen to guide often reluctant players to a successful result. Nor are the usual players responsible for the client’s vision. It is up to the client to decide what they need and what they are willing to do to get it. As for me I’d been deeply unhappy with the divide between instruments and control systems for 25 years. FF breaks down that wall giving me vision into how the instruments and valves are working and allows me to take advantage of that knowledge to craft more robust control. To me it’s worth the effort. Ed Bullerdiek


RSS feed for comments on this page | RSS feed for all comments