All entry results tagged with “macrocycle”

John Rezabek closes his ControlGlobal.com Surprise! Field-Based Control Beats DCS article with the thought:

The SP50 committee set out years ago to define and specify a robust, vendor-independent controls suite exploiting the intelligence of microprocessor-based field devices that would equal or exceed the "bulletproof" DCSs of the 90s. They succeeded.

The source of this conclusion is two recent studies, one conducted by Emerson fieldbus consultants Dan Daugherty, Mark Coughran, and Ferrill Ford. The other is by Kenexis Consulting's Ed Marszal, who applied a similar reliability model used with safety instrumented functions to Foundation fieldbus (FF) control loops running PID in the FF device. The common vernacular for this type of control is control-in-the-field (CIF). I described and embedded Dan, Mark, and Ferrill's Emerson Exchange presentation in a post, Dispelling a Rules of Thumb in Foundation Fieldbus Segment Sampling Rate. In John's article, he summarizes this study:

One of the things revealed was that control in DCS did not benefit substantially from over-sampling, which involves running the macrocycle two or more times faster than the DCS PID block. The other notable result was that control-in-DCS could not approach CIF in performance, especially when macrocycles (the deterministic cycle time of all the function blocks on a fieldbus segment) were cranked down to as little as 150 milliseconds. CIF was distinctly better and had no problem matching the performance of fast, pure analog (4-20 mA) control.

Control in the field has the advantage of single loop integrity, diagnostics, and signal status across the fieldbus segment. For the reliability study comparing control in a DCS controller versus CIF for a simple PID loop, John quotes Ed's findings:

Fieldbus is significantly better--mean time to fail (MTTF) of 48.2 [years] versus MTTF of 15.9 [years].

The numbers were rerun using field devices with the same reliability numbers and the CIF case again had greater MTTF. I sent Dan a link to the article and asked what thoughts he might have to share. He wrote:

It is good to see confirmation of our conclusions from independent researchers using different methods of analysis. In the tests ran in the Marshalltown flow lab, Mark Coughran, Ferrill Ford and I not only demonstrated the superior performance of FOUNDATION fieldbus deployed as Control-in-Field (CIF), but were able to show the relative contributions of the control algorithm update rate and the I/O sampling rate of the macrocycle. This is useful information for economical control system design to the necessary performance requirements. We were able to dispel the myths that inhibited the choice of FOUNDATION fieldbus due to unnecessary overdesign, which in turn leads to low density and higher cost segment design.

I fully concur with the conclusions that use of FOUNDATION fieldbus can lead to higher availability than one can get with point-to-point I/O. Without going into all the complicated algebra, the common sense view is that one H1 card for 16 loops (8 loops per segment x 2 segments per card) will have a lower failure rate than 4 I/O cards for the same number of loops. Then once one chooses to use redundant H1 cards and fieldbus power supplies, the availability is much, much higher. Clearly, FOUNDATION fieldbus is by far the most reliable way to deploy control. (I assume that by now, everyone understands individual devices and short circuits are isolated from the segment through the field connection hardware.)

Given these performance and reliability results, the case favoring this highly distributed control-in-the-field approach continues to build.

MP3 | iTunes

On the Fieldbus Foundation Forums is a recent post, Macrocycle for control in the controller. The post begins:

I have seen many posts about scheduling and macrocycle calculation for control-in-the-field (CIF). I have some doubts about control-in-the-controller (CIC) application. Unfortunately, there is no other option in the project I am working for.

The question asks about acyclic vs. cyclic communications, macrocycle communications, and loop response time.

ISP Lima Process Control Specialist and Control magazine contributing editor, John Rezabek, contributed to the conversation. He referenced a post I had done previewing one of the Emerson Exchange presentations, Control Response Period for Foundation Fieldbus Control-in-the-Field Loops. This presentation was given by Emerson fieldbus consultants Dan Daugherty, Ferrill Ford, and control performance consultant, Mark Coughran.

Here's their presentation, which tested and compared control performance for CIC and CIF:

Dan shared a few thoughts with me that I wanted to pass along specific to control in the controller and control in the field considerations. He said most process control engineers don't know how slow the modes they need to control are. The performance for control loops where control is performed within a Foundation fieldbus (FF) device will always be better, but if the engineer imposes reasonable rules on the use of CIC, it will work well.

Some want to do CIC to avoid the fieldbus segment design calculations and others encounter problems once they do the calculations and commission the segment. In some automation systems like the DeltaV system, the Foundation fieldbus H1 card can run the control loop. Since it's directly connected to the fieldbus segment, the latency of passing information up to the controller is avoided. This significantly reduces the number of applications requiring CIC.

Dan takes issue with rule of thumb developed over the years where the segment-sampling rate is 2X the controller update rate. He believes this is a misapplication of Shannon's sampling theorem. The problem is not that it doesn't work; it's that it increases the cost of project due to fewer devices per fieldbus segment.

Deciding that none of their theoretical arguments, diagrams, and Laplace transforms was having an impact with the 2X sampling belief, Dan, Mark, and Ferrill performed tests in the Fisher Marshalltown flow lab. Dan summarized the most important thing he learned from the test:

Once the loop control mode frequencies are identified, then you choose your control settings so the closed loop transfer function attenuates that frequency. And you need your control update rate to be somewhat faster than that. When we were looking at update rates in the ¼ and ½-second range, we essentially had an update rate that was 25 to 50 times the frequency of the mode we wanted to control, and 2.5 to 5 times 10x the frequency we were trying to control.

He concluded:

It's true that CIF, with super precise determinism, gave the very best control. But CIC gave pretty good control. So, it wasn't really a question of whether or not to use CIC or CIF (because CIF is clearly better), but if circumstances made it necessary to use CIC whether or not it was better to oversample at a slow update rate or to get one-to-one sampling at a faster control update rate. It turns out the faster control update rate gives you more for the money than oversampling at a slower control update rate does. However, note that this line of reasoning applies mainly to continuously changing disturbances.

So, first you need to understand what you are really trying to control, and how good is good enough. That determines your control update rate. Second, once you have a control update rate, then see how much you are willing to load the segment (devices per segment, for economic reasons). If you are forced to use CIC, and if that maximum loading doesn't allow oversampling, then don't oversample. If you are forced to use CIC, and if that if the maximum loading allows oversampling, then by all means oversample.

If you are using CIC, then what you gain by oversampling is a slightly better attenuation of the disturbance frequency, AND a significant improvement in end-to-end response time. So, if you have a process that is mostly flat lined, but every once in a while some rather sudden change occurs, an oversampled segment will have an initial response that is a little quicker than one that isn't oversampled, and if you are using any discrete logic, then you will have a little quicker end-to-end response to the field input.

As for estimating "required" macrocycle times, that varies by method used (number of compel data communications required), speed of devices, and number of devices. CIC requires more compel data per macrocycle, so it will tend to make the macrocycle about 2x longer than if CIF were used.

Our interest in the experiment wasn't to see if CIF or CIC was better, but to determine if oversampling was worth it. Given the already longer macrocycle with CIC, in my opinion, it is a needless self-imposed penalty to oversample, which (for same number of devices) now takes your control update rate out to 4x what you could get with CIF. So, you get worse control because it is CIC, and worse again on top of that because you slowed down even more to oversample.

MP3 | iTunes

A great question came in the Process Automation Usability Project forum asking why there is not more control in the field being done. If you're unfamiliar with the term, it's where a Foundation fieldbus (FF) transmitter, digital valve controller, or other instrument runs the control logic for the loop, instead of this being done in the automation system controller.

When I saw the question, I bounced it over to Emerson fieldbus consultant Dan Daugherty, whom you may recall from earlier fieldbus-related posts. Dan made a couple of great points, the first on segment design:

If you do control-in-controller, and you don't care a whole lot about process segregation (only do it on a coarse, controller level), then you can skip all the concerns regarding segment design except for voltage drop and number of devices. Many engineering companies didn't want to learn segment design, so they stuck with control-in-controller.

His second point dealt with the complexity of the control strategy used:

...some control strategies are complex enough they can't be done on a single segment (prior to 2007) because not all the control functions they wanted to use were available in devices. That is no longer true with Emerson because we have ability to pick up functions in the H1 card, effectively filling out any gaps that used to exist in the control-in-field palette of functions.

His third point is that there are economic and performance advantages to using control in the field. In his response, he references a presentation that he and some colleagues are giving at the upcoming Sep 28-Oct 2 Emerson Exchange conference, Effects of Macrocycle Time and Sampling Rates on Control Loop Performance.

The team set up controlled tests in Emerson's Marshalltown Flow Lab to compare performance between Foundation fieldbus and conventional 4-20mA analog loops for control response period, load frequency response, and setpoint step response.

Their tests showed that with FF control in the field, the control response period equaled the macrocycle and they could get 0.18 seconds, which is adequate for almost all loops. The exceptional loops that require faster response times, such as surge control and compressor lube oil, typically have dedicated controllers. Dan does however reference a 2008 Emerson Exchange presentation where field-based control was successfully performed in a compressor anti-surge application.

Another important finding is that there is even more reason to use control in the field as the number of loops on a fieldbus segment increases. The control response period is much greater when control is performed in the automation system controller than when control is executing in an FF device when they looked at 8 loops on a fieldbus segment.

If you'll be joining us in Orlando at the Emerson Exchange, you may want to check out Dan and team's presentation. One session will be Sep 29 at 11am and the second on Oct 1 at 10am. Visit the Personal Scheduler to plan the all sessions you want to see.

MP3 | iTunes