Macrocycle for control in the controller

[tfreitass]

Dear all,

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.

1) The communication between DCS controller signals related to control and FF devices in a H1 segment is acyclic or cyclic? Considering a single loop, I supose that data sent by DCS controller (PID output) is acyclic and data received by DCS controller (BCALC) is cyclic. Is that correct?

2) Considering the answer to item 01, how can I calculate the macrocycle (required macrocyle: FB processing + communication)? My assumption for a single loop is:

macrocycle = AI_processing + AI_publishSubscribe + AOprocessing + BCALC_publishSubscribe

3) How can I calculate the response time? By response time I mean, in a single loop example, the time between the transmitter receive a new input signal and actuator receive control signal related to this new input signal. My assumption, again for a single loop, is:

response_time = (2 x macrocycle) + DCS_controlProcessing + DCS_acyclicCommunication

Thanks in advance.
Regards

[CHRISC1024]

The first thing you need to know is the execution time of each block you are using in each device. This information is readily available from teh vendor and is even in the device files. Take each device and add up the execution time for the blocks youa re using then add all the device on the segment together to get your scheduled traffic time. Then you want to figure in your unscheduled traffic time. I ususally double my scheduled traffic time and this is what I allow for my unscheduled traffic.

Calculated scheduled traffic+what you want for unscheduled traffic = your macrocycle. Some of this might also be dependant on what your proccess time will allow. Normally this is not an issue but it is not uncommon to have a 1 sec or more macrocycle if you have say 8 or more devices on your segment.

Are you trying to figure this out for a new design or a current application?

[agupta]

1) If the AI and AO and all other FB in devices on one segment, are executed at the same periodic rate, then the macrocycle is equal to that period. It is not the sum as defined by you.
2) If the control is done in the field devices, then the response time can be as short as what you define as the macrocycle.
Response time = AI execution time + time to publish AI-output + execution time of PID + time to publish PID-output + time to execute the AO.
Note - LAS schedule has to be coordinated with the FB execution schedule.
3) If the control is done in the host controller and its time is not synchronized with the fieldbus time, then do following:
Use cyclic (Publish) communication to publish AI-output. If the controller allows it then publish its PID-output as well.
Allow a time equal (slightly larger) to PID execution time between the AI-output publishing and PID-output publishing.
The minimum response time = AI execution time + time to publish AI-output + execution time of PID + time to publish PID-output + time to execute the AO.
The maximum response time = AI execution period (macrocycle) + The minimum response time.
Since the controller is not synchronized, the response time varies between the minimum and the maximum.
4) If the controller does not allow to publish its PID-output, then use acyclic communication to write PID-output to the AO FB.
The minimum response time = AI execution time + time to publish AI-output + execution time of PID + time to write PID-output (variable depending upon the bus traffic) + time to execute the AO.
The maximum response time = AI execution period (macrocycle) + The minimum response time.

[rezabejd]

Originally Posted by tfreitass

Dear all,

]1) The communication between DCS controller signals related to control and FF devices in a H1 segment is acyclic or cyclic? Considering a single loop, I suppose that data sent by DCS controller (PID output) is acyclic and data received by DCS controller (BCALC) is cyclic. Is that correct?]

I think the answer is host-dependent and may still not reflect reality. On the system I use, control outputs show up as cyclic "publish" events (compel data) on the macrocycle schedule, but there's not any guarantee that the controller-resident PID has actually solved a new output at the time the H1 link master blasts out the (supposedly new) number. The H1 link master is not innately capable of "scheduling" the host-resident PID block.

Originally Posted by tfreitass

2) Considering the answer to item 01, how can I calculate the macrocycle (required macrocyle: FB processing + communication)? My assumption for a single loop is:

macrocycle = AI_processing + AI_publishSubscribe + AOprocessing + BCALC_publishSubscribe

"Required macrocycle" only depends on the field function block load (how many and how long for each) and the number of required "compel data" or publish events, plus some allocation for acyclic comms (recommendations vary). Control in host would typically add at least one more compel data that would usually be absent in the field (with PID solved in either the AO-containing device or the AI-containing device).

Originally Posted by tfreitass

3) How can I calculate the response time? By response time I mean, in a single loop example, the time between the transmitter receive a new input signal and actuator receive control signal related to this new input signal. My assumption, again for a single loop, is:

response_time = (2 x macrocycle) + DCS_controlProcessing + DCS_acyclicCommunication

The only meaningful (to me) study I've seen was done by some Emerson people in their flow lab. They had to prove the data empirically. Their Jim Cahill makes reference to it here. Maybe some nice Emerson person can upload the PDF to our thread?? The gist of it is, macrocycle and controller module execution did not predict response times.

[tfreitass]

Originally Posted by rezabejd

The gist of it is, macrocycle and controller module execution did not predict response times.

I agree that macrocycle and controller module execution do not predict a precise value for response time. Although, I believe it is possible to calculate a range for response time (as stated by agupta) if some assumptions were adopted. Example below:

1) Single loop (CIC);

2) DCS calculate control async, but sends data by a FF interface module synchronously;

3) Schedule macrocycle of 250ms = AI_execution (50ms) + AI_publishComm (25ms) + PIDoutupPublishComm (25ms) + AO_execution (50ms) + AO_BCALPublishComm (25ms) + UnscheduledCommunicationProvision (75ms);

4) DCS PID execution rate lower than 500ms.

In this scenario,response time estimated range would be 675ms to 925ms. 675ms is the minimum response time, considering response in the 3rd macrocycle (PID execute and send output in less than 500ms) and 925ms is the maximum value is considering response in the 4th macrocycle (PID execute and send output in less than 750ms - supposing any kind of latency in DCS).

[rezabejd]

Agreed - estimating a range of response times is plausible. Nothing like some empirical tests to bear out the theory - see attached PDF. One of its authors (Dan Daugherty) commented that CIC (control in controller) is often "good enough", which I wouldn't dispute. The number of loops requiring very fast response times is relatively small, but sometimes licensors impose strict requirements on their licensees, which I think was the impetus behind this study.

Without the rigid dictates of a process licensor, one can base required macrocycle on actual process dynamics. Daugherty says oversampling (FF macrocycle faster than CIC execution time) can help and is an option if your segment loading economics permit it, but the fundamental disturbance attenuation capabilities hinge on the controller cycle time.

Thanks to the guys at Emerson who gave us permission to upload their paper. Jim Cahill is says he's contemplating a future blog post on the subject.

[EmersonsJimCahi]

Hi John, Thanks for the link to my post. I checked with Dan Daugherty, Mark Coughran, and Ferrill Ford, and here's the link to their 2009 Emerson Exchange presentation, Effects of Macrocycle Time and Sampling Rates on Control Loop Performance

I'm working on a blog post to capture some of their additional thoughts.

[jberge]

My two cents for additional clarity:

“macrocycle” is period of the fieldbus schedule. Central DCS controllers are not synchronized with the underlying fieldbuses, thus there is no macrocycle for control in the central DCS controller.

However, there are systems out there that support control in H1 fieldbus interface card, which is part of the DCS, and thus this is technically a DCS loop synchronized with the fieldbus. In this case, the macrocycle can be calculated as easily as for CIF.

Do not confuse cyclic/acyclic with synchronous/asynchronous

Cyclic = data is sent on a regular basis. This applies to all real-time data such as PV for closed loop control and PID output. For FF this is done using publisher/subscriber communication.

Acyclic = data is only sent as and when required. For example mode or setpoint change from operator, or read data for a faceplate. For FF this is done using client/server communication.

Synchronous = all devices have common sense of time (synchronized clocks) and all communication and control follows a predetermined scheduled shared by all. The schedule ensures the PV is prepared just in time before it is communicated to the PID, and the PID is executed just after the PV is received, and PID output is sent to the positioner just before it corrects the valve position to. The response period is precisely the same every time. Constant sampling period is ideal for PID control, especially fast loops like flow and pressure. This is easily achieved using CIF.

Asynchronous = devices have no common sense of time (clocks are synchronized). Therefore, the PV may arrive at the PID just after the controller cycle started, meaning the PV is only used in the next cycle. The output from the PID may become ready just after the bus cycle started, meaning the output is only send to the positioner in the next bus cycle. Some cycles the response is fast. Some cycles the response is slow. The difference in response time is called “jitter”. Control in the controller (CIC) is asynchronous. This works OK for slower processes like level and temperature.

For instance, Profibus-DP/PA supports both cyclic and acyclic communication, but control is asynchronous because Profibus has no time synchronization or schedule. This is why Profibus-DP/PA are not so popular in industries with many PID loops such as refining, petrochemicals, and chemicals.

1) All real-time values in a closed control loop are cyclic: both transmitter-DCS and DCS-positioner

2) The response time for Control in the controller (CIC) is:
- One fieldbus macrocycle to get the value from the transmitter to the DCS.
- With some luck the value arrives in the DCS just BEFORE the controller cycle starts and gets used immediately, but worst case it arrives in the DCS just AFTER the controller cycle starts in which case it must wait for the next cycle, so the delay varies from anywhere between one to two DCS cycles.
- With some luck the DCS controller cycle completes value just BEFORE the bus macrocycle starts and the outputs gets sent to the positioner immediately, but worst case the DCS cycle completes just AFTER the fieldbus macrocycle started in which case it must wait for the next macrocycle, so the delay varies from anywhere between one to two macrocycles.

That is:
- When you do CIC you cannot count individual block and link times, you must count cycle times
- The time is longer
- There will be jitter, within a known range

Keep in mind the FF schedule is created automatically by the control system engineering station, you need not configure it manually. This makes FF easy.