Response to Foundation Fieldbus and Profibus PA Cost Comparison Whitepaper - Emerson Automation Experts

Response to Foundation Fieldbus and Profibus PA Cost Comparison Whitepaper

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.

Posted Thursday, February 21st, 2008 under Foundation Fieldbus, Interoperability, Profibus.


  1. 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 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.

  2. 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:

    FF is deterministic to 1 millisecond (hardly ANY variance at all). PA (in the example) is deterministic to 400 milliseconds with an average latency of 200 milliseconds. For a control loop updating every 1/2 second, FF is right on the nose (1 millisecond determinism) and PA (in the example) is 0-400 milliseconds old (not a fixed latency) at time of control algorithm update. If PA is oversampled (requiring dropping number of devices to 12), then the latency tolerance is better at 0-200 milliseconds (still not a fixed latency) and still considerably sloppier than FF. As for “recommendations”, please explain why PROFIBUS is comfortable recommending a device count that causes 0-400 milliseconds latency. FF is clearly more conservative in its recommendations which preserve the 1 millisecond determinism. Another question for PROFIBUS: are those 24 devices bus-powered? Because the 12-16 devices on FF are indeed bus powered.

    In the “easier” section of the post, I’ll quote Dan:

    Again, there is no additional “overhead.” PA devices also have to execute software internally, but PROFIBUS tries to make the reader believe its software isn’t “overhead.” FF simply organizes its software into Function Blocks. But it’s still just software. Again, with FF, the user doesn’t have to set up macrocycles or block linkages. That’s all completely transparent. In fact, the FF user draws a picture, a block diagram of how data is to flow in control logic. Guess what? This is EXACTLY the same diagram the user draws for 4-20 ma devices! So: NO extra work. The diagram is translated/compiled by the development system software so it completely transparent to the user and couldn’t possibly be easier.

    With FF, the end user wouldn’t gain anything from “the protocol being the same” because the end user is frankly not even aware that there is a protocol. The end user has a control logic drawing and results. What protocol? Working with DP and PA, the end user is PAINFULLY aware that there is a protocol. With PROFIBUS, instead of simple logic drawings, one has to be knowledgeable of bit positions and meanings of bits, start positions, etc. And give up on timing. You get what you get, whenever the bus master gets around to doing it.

    And again: NO LINKING DEVICES ARE REQUIRED WITH FF! But they ARE required with PA!

    The benefits of buses are clear, but the time to try is before you buy.

  3. John Rezabek says:

    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.

  4. 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 – for FF and 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.

  5. 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… 🙂

  6. p.manjula says:

    yes these commant is very good ur very gud decision to him ok na buy

  7. Renato Veiga says:

    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.
    – 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.
    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.

  8. rajendrakumar says:

    yes im agaree

  9. Augustin Mingueli says:


  10. says:

    thanks for you job, i learned much

Leave a Reply