The Foundation Fieldbus Loop Keeps On Keeping On

Here is another installment in our continuing series of screencasts showing the intersection of Foundation fieldbus (FF) digital communications with automation systems. The intent of these screencasts is to demonstrate visually how the information in these smart field devices interacts with the automation system to help improve the process.

Emerson’s Rune Reppenhagen shows a control loop with a Coriolis flowmeter, a digital valve controller, and a connection to a redundant pair of Foundation fieldbus H1 cards. Rune describes the control strategy where the analog input runs in the Micro Motion transmitter, the PID control block and analog output block run in the Fieldvue DVC6000 digital valve controller and fieldbus segments connects to the pair of DeltaV H1 cards.

In this 3:21 screencast, Rune shows how control around the loop is maintained by running even in the event of loss of both H1 cards. As you might expect, the information is no longer transmitter to the operator, but the loop will continue to operate. Operators can monitor the loop locally at the devices with their local indicators until the communications are reestablished.

Different applications and operating philosophies may prompt where you might want to locate your control strategies–in the automation system controller or in Foundation fieldbus devices. John Rezabek, a contributing editor for Control magazine, implemented this approach seven years ago as he describes in his article, Not jazzed about fieldbus? Try it. He describes the additional benefit of mode-shedding to manual when the process variable (PV) of the PID is bad or uncertain in the devices. John writes:

While it’s a diligent piece of work, this user-coded mode shedding is utterly unnecessary in fieldbus–it’s already hard-coded into the blockware and happens automatically. In the same way, the “actual” mode of a PID block sheds to manual when its PV status is bad or uncertain, holding the last output computed before the input’s signal status changed.

For bad or uncertain transmitter information, John writes:

Bad or uncertain PV status will cause appropriate mode-shedding in the same scan (macro cycle) in which the condition is detected, so no “new” valve output is passed to the AO block; it dutifully holds last value.

All this happens by interconnecting the FF signals via your programming interface. No additional code or external interlocks are necessary. It’s built-in, out-of-the-box and standard in certified FF devices that have implemented PID.

The bottom line from the screencast and what John writes is that Foundation fieldbus provides a lot of robustness in control in addition to the digital diagnostics it delivers.

Posted Thursday, July 12th, 2007 under Foundation Fieldbus, Screencast.

2 comments

  1. John Rezabek says:

    Is DeltaV distinctive in the way the FF function blocks, parameters, and status handling is carried throughout the system? While at BP, we tested DeltaV and a number of your competitors’ “internal” function blocks, and all of them did “mode shedding” consistent with the FF model. What was less clear was whether the granular FF status was carried on throughout the control scheme.
    Anyhow, it may interest your readers that even when PID is solved in most modern host systems, the fault-tolerance enabled by FF is utilized and exploited.
    Emerson’s leadership in this area is much appreciated, and as an end-user I’m happy to see “best practice” examples like Rune’s out there, even though having a DCS that supports fieldbus isn’t as big a differentiator as it was a few years ago . . .

  2. John, Thanks for your comment. I checked with Terry Blevins on your question and although he does not have specific knowledge on other suppliers Foundation fieldbus implementations, in his role as team leader for the Fieldbus Foundation function block specification maintenance, he has the unique opportunity to interact with technical leads from the major control system suppliers.
    Based on these interactions, he thinks that there is good understanding and support of the FF function block specification. It has taken some time for this understanding to develop within our industry. However, as manufacturers have adopted FF and addressed the integration of FF devices into their system, this understanding is necessary.
    Since the DeltaV system was developed about the time the FF specifications were finalized, it had the benefit of being able to design the system from the ground up to fully support FF devices and to seamlessly integrate FF into the system. Also, many people within the Emerson organization contributed to the development of the FF specifications and thus there was good understanding of the technology.
    Suppliers with existing systems have had a much harder time of integrating FF into their system since in many cases a block set already existed and the concept of status existed but was different from that defined by the FF specification.
    Terry thinks it would make sense as other suppliers develop new versions that they follow this approach in the way FF is seamlessly integrated into the control system. However, some of the patented innovations in the way FF is applied within the DeltaV system will remain unique to Emerson for some time to come.
    He cites an example of the use status by diagnostic tools such as DeltaV Insight to identify and summarize measurements that have Bad or Uncertain quality or control that is limited. Another is on the implementation approach to support autotuning of PID in FF devices. A final one is the approach taken in implementing function blocks in the H1 card to allow scheduling of synchronous execution.
    Take it easy, Jim

Leave a Reply