Update: This post is from originally from 2008. It recently came up in an “archived tweet” message. The “fieldbus wars” have cooled considerably in the time between the original post and now… thanks for stopping by!
ORIGINAL POST: In the early days of Foundation fieldbus back in 1996 and 1997, we used to do capital expenditure (CAPEX) comparisons of installations installing Foundation fieldbus versus what they would have cost installing conventional I/O. The savings were pretty eye opening in terms of material and labor savings, commissioning time, and control room space savings.
The big part we missed, because there hadn’t been enough run-time, was the much larger operational benefits available through abnormal situation prevention, predictive maintenance, and improved control.
I bring all this up because I found in RSS feeds recently the article, Reviewed resource: Profibus PA and Foundation Fieldbus–a cost comparison, on the Control Engineering website. The whitepaper was developed by the Profibus Trade Organization.
The focus of this study was a CAPEX look at the differences between Foundation fieldbus (FF) and Profibus PA installation. The report concluded that: Profibus PA devices are less expensive, one can fit far more PA devices on a segment than comparable FF devices, the links are less expensive, and PA is easier.
My initial reaction was not suitable for family reading, so I ran it by some folks, including Emerson fieldbus consultant Dan Daugherty, who is both a Foundation fieldbus expert and a Certified Profibus Network Engineer. His initial response to me was also not suitable for family reading, so I put the post I’d worked up aside for several days of calm reflection. So now, here we go…
One argument made was that PA devices cost less than FF devices due to extra memory and processing power needed in Ff. While not conceding that this is true, and not wishing to discuss pricing on this blog, I’ll simply say from classic economics 101, that price is determined by the market, based on the value received and not the cost to make.
I’m not sure what automation system was considered in the analysis, but the study claimed costs associated with a “linking device” in Foundation fieldbus. In systems like the DeltaV system, the FF segment connects directly to an FF input card in the I/O subsystem, as do other buses like Profibus DP, DeviceNet, and AS-i bus. A PA device cannot be directly connected to a host system, but rather must come through a linking device. In the DeltaV system, a PA device is connected through a linking device to a Profibus DP segment.
As Dan points out, this introduces increased engineering, increased maintenance, and a higher probability of failure on demand with these additional components. This impacts both capital expenditures and ongoing operational expenditures.
Another claim in the whitepaper is that more PA devices can be put on a segment than FF devices. Dan notes that since communications on a PA segment are not deterministic, to deliver the same control update period as FF, say the 400msec mentioned in the whitepaper, it must oversample and reduce the number of devices. In this 400msec case, an FF segment can run 6 control loops (12 devices.) A PA segment would need to drop from 24 to 12 devices and sample at 200msec to achieve this 400msec control update period.
Voltage drop on a bus-powered bus is also a constraint. It’s a function of the length of the segment (trunk plus spurs) and the current draw of the devices on the segment. In order to get the bus lengths typically seen in process manufacturing applications, there’s little chance of ever finding 24 devices on a segment. FF can allow 16 bus-powered devices, but the typical practical loading, constrained by voltage drop (same rules for PA) usually makes 12 devices a more typical real-world implementation. Also, typical plant practices partition segments by geographic region, process criticality, and future growth capacity, which also limit segment device counts.
The easier/less-complex claim is the biggest head scratcher. PA and FF have the same physical layer so grounding and other physical installation considerations are similar. From a device-commissioning standpoint, I’m not sure what’s easier than connecting a Foundation fieldbus device to a segment, having it automatically recognized by the system, and quickly commissioned into operation. When you have to introduce a linking device into the mix, it gets harder, not easier. Especially when there is RS-485 running on DP and bus-powered Manchester Biphase on PA, each requiring separate tools and linking devices.
This post could go on and on to discuss the operational benefits associated with Foundation Fieldbus in abnormal situation prevention, robustness, ongoing calibration savings and even autotuning within the device, but I think this is a good stopping point.
Related Posts
More on Foundation Fieldbus and HART
Calculating Foundation Fieldbus Segment Loading
Control Response Period for Foundation Fieldbus Control-in-the-Field Loops
Diagnostics in Device Busses Improve Operations
The Case for Control in the Field-based Control
Dispelling a Rules of Thumb in Foundation Fieldbus Segment Sampling Rate
I think discussion of the pro’s and con’s of both FF and PROFIBUS PA is worthwhile. Jim, I’ve compiled a response to your response and posted it at http://www.PROFIblog.com. I urge readers to not become distracted though. Don’t let the discussion lead to analysis paralysis. Read about fieldbuses. Try a small project with each one. Then pick one and save installation, commissioning, and operational costs.
Carl, Thanks for your comment. Unfortunately dubious comparative whitepapers can be a source of confusion and distraction.
Again to help clarify the prevailing confusion, you NEVER need a linking devices if your controller has a direct I/O card. Repeaters for long runs with both FF and PA yes, but linking devices and their associated extra work, only with Profibus PA.
For the determinism section of the post, let me quote Dan:
In the “easier” section of the post, I’ll quote Dan:
The benefits of buses are clear, but the time to try is before you buy.
While my friends at the Foundation wince when I say it, I like Dick Caro’s take on fieldbus choice, which I paraphrase as “use what your favorite host vendor is good at”. So if you love Siemens, then perhaps FF is not the optimum choice.
The whole argument about segment loading is flawed, especially for the process industries. When Martin Berutti (now with Mynah) quote our first FF project, he estimated 16 deivces per loop and sized the system based on that. Good thing sales guys know how to take a beating. We ended up averaging 5 devices per loop initially, based primarily on process robustness issues.
Shame on our end-users for not updating AG-181, upon which the gents at Die PROFIBUS Nutzerorganisation based their comparison. AG-181 is outdated and in need of updating. Novices should note that end-users are largely responsible for the FF Systems Engineering guide – we don’t get paid for our input. This is one of the main reasons the needed update has been late in coming. It’s one thing to herd cats, and another when the cats are swamped with multiple new FF projects.
I guess we could continue “correcting” each other indefinitely, but we are not going to change each other’s minds. Instead, I would encourage potential users of a fieldbus to do their own research and test the technologies on their own as you suggest. There is a lot of misinformation out there, so weigh the evidence carefully and consider the source of the information. So start with each organization’s website – http://www.fieldbus.org for FF and http://www.us.profibus.com for PROFIBUS. We are confident that when compared side by side, end users will find that for most applications, PROFIBUS offers better value. But in the end, it’s up to the users.
John, Thanks for your comment and Carl, thanks for yours.
As John points out, selection of the host is a critical factor in the user experience with either bus.
For busy folks, we’ve tried to help with screencasts to show where the real value is, in the operational benefits.
I wholeheartedly agree that self-education is a great course… just be wary of some of the whitepapers you might come across… 🙂
:$
yes these commant is very good ur very gud decision to him ok na buy
My View Point:
– FF is more efficient for user configuration. Function Blocks transform configuration work into a LEGO for adults. FF Application Layer Standardization, for me, is the best feature (unique) of any competitor protocol.
But:
– I disagree with your “Link Device” opinion. Many manufacturers start to develop Profibus PA cards to access PA Bus without Profibus DP.
– For end user, a little possibility to put 32 slaves instead 16 only is very attractive
– FF don’t have a “DP Like” solution for hi-speed multi-drop bus (like 12Mbps Profibus DP). Many cases, like Machine Control Center (Motor Drives Network) Application will be better solved with Profibus DP. In this case FF-HSE could cover speed requeriments, but installation will became difficult and expensive.
– With FF many times we have many interoperability problems. With Profibus, we never have. Where is the cause ? I think standard must close all misunderstanding issues.
Ending:
FF its a great organization, have all oil/gas market. But is losing others to PA. HSE is ethernet based and is very good to make communication between linking devices. But needs more modifications to compete with others. HSE-RIO is good initiative, but can be late.
yes im agaree
I APPRECIAT YOUR ORGANISATION.
NOW WE WANT TO SUPPORT OUR ORGANISATION WITH GRANT AND OTHERS BENEFITS.
THANK YOU.
thanks for you job, i learned much
fieldbus.tv