Hi Can the DeltaV controller able to handle following response time:
1.Digital SOE inputs scan rate 0.001 second.
2. Modulating control logic and calculations process at every 0.5 second with the capability to process at least 10 percent of the logic at a 0.1 second interval.
3. Alarm display and operator command respond in not more than 1 sec
.
Yes.
SOE card is 0.25 ms on the card (between channels on same card) and 1 ms for all channels on same controller. 4 ms across the system due to ability to synchronize all controllers and this requires NTP server on network.
DeltaV controllers support 100 ms execution. Running all control at 500 ms or faster will consume controller processor faster, so you will have fewer modules before you run out of CPU. You can always run 10 % of modules at 100 ms, but the actual number of modules running in the controller will be determined by available CPU. Number of modules depends on module complexity. So the answer to your question is yes DeltaV controller can meet this requirement.
Typically DeltaV communciations to console is done on 1 second update rate. Response time to Operator command requires that the module actually execute to carry out the operator command. The write is done immediately, the module executes, and the resulting logic may arrive between 0.25 to 1.5 seconds. On average it would be less than 1 second. the Process however would take several seconds to show a responase due to process lags, including those of the control elements and other deadtimes in the loop.
As for alarm display, A better question would be where is the alarm time stamp applied. If the Alarm time stamp is applied at the console, reporting lag can result in incorrect sequence of events, and could lead to incorrect action on part of operator. If the alarm occurence time is captured in the controller, the correct time stamp will show cause and effect in the alarm list and summary, allowing Operator to properly evaluate process conditions. Alarms require a reasonable time to respond (per ISA 18.2) and if the alarm system is properly designed, with accurate time stamps, then a 1 or 2 second delay in reporting the alarm will not matter. DeltaV detects alarms in the Control module (or in device with FF) where the time stamp is applied. Alarms are reported as events and typically within a second, with a time resolution is to the millisecond and accuracy based on module execution.
Andre Dicaire
In reply to Andre Dicaire:
Andre, Thanks for the good information. I have a question along these lines that you may have the answer. How is order of execution established for DV modules? also related to module execution rate? In a controller, if there are 10 modules running at 500 ms and 100 modules running at 1 sec, which one goes first of the 10 at 500ms?, are they run simultaneously as the '500 ms block of modules'? how is priority established? I do not have any current problem with this, just curious. I looked for a whitepaper or more information on this but could not find one.
In reply to Sean Brady:
You might want to check out the "Control Module Execution" Whitepaper below. It'll answer most of your questions...
http://www2.emersonprocess.com/siteadmincenter/PM%20DeltaV%20Documents/Whitepapers/WP_controlmoduleexecution.pdf
In reply to Tyler Anderson:
Hi Sean,
When complete controller is downloaded, the execution starts with module names starting with 0 to 9, then A to Z. No two modules (any execution tasks) are executed simulteniously.
All the modules execute in first scan. If you have modules with 500ms & 1 sec scan rates in configuration, then the modules with 500ms scanrate would execute in second iteration after 500ms, skipping the modules with 1 sec scan rate into that iteration... at the next iteration after 1 sec, all the modules will execute, & so on..... But the sequence of execution does not alter.
This is until you perform any partial download on the controller. Upon partial download of any modules, the execution order for these modules will change to execute them at the end.
If the controller is overloaded, then the low priority modules would miss their execution place & would execute arbitarily into any next available time slot.
In reply to amodbobade:
Amodbobade is not quite correct. The DeltaV controller scheduler balances module exeuction over multiple time slices per second. He is correct to state that only one module is executed at a time. However, as modules are downloaded, the scheduler distributes them across these time slices to keep each time slice balanced. I beleive the time slice is 50 ms, but it really does not matter.
Say there are 20 time slices in a second (50 * 20 = 1000ms) If you have 20 1 second modules, each time slice will have one module, and evey second, all 20 modules will execute. If you had 40 modules at 1 second, you'd have 2 modules per time slice. If you had 10 500 ms modules, you would have 1 of these for the first 10 time slices, and the same ones again for the next 10 slices, so that after 1 second, all ten modules have executed twice.
So there is never one time slice where all modules are scheduled at the same time slice.
When you do a total download, DeltaV does send the modules in alphabetical order, but as modules are scheduled, the order of execution will depend on scan rate of those modules as the scheduler balances the time slices. So it is futile to attempt to understand or even care about execution order of the modules. As time goes on and partial downloads occur, modules are rescheduled, so they can "move" in the order.
So what happens when you have two modules that interact (Cascade loop, COntrol select, Feed Forward)? On a total download, it is possible that the secondary loop executes before the Primary loop.
First, if you never perform a total download while the plant is running, this situation will not be of any consequence, as all valus and status will line out within a few seconds. By design the DeltaV controller will aling the AO and DO blocks in modules to the current state (value) of their referenced IO Channel during the first scann and the block will transition from IMAN to the target mode, and will initialize with the upstream block via the BKCAL signal However, once the initialization is done, the control module logic will drive the value to whatever the logic decides. It is the user configuration that will bump the process, even on a total download.
DeltaV provides the signal Status (.st) and also the connection status (.cst) and options to evaluate the quality of signals before using them in logic to possibly drive an output inappropriately. Total downloads result in initialization and modules with external references that could disrupt control signals should uses these status atttributes to determine ensure bumpless total download. There is also a download flag that can be used by each module to know if it is executing an initial scan following a download or switchover.
You should treat every module as if it is executing first followign a total download. If it uses external data, either local or remote, the module should use status and CST to avoid spurious trips or bad calculation results. For any parameters that are not initialized to a valid usable value, the status of that parameter should remain BAD, until the module has executed and set the value and its status to good.
This last point is important when manipulating a parmaeter with a CALC block. If the value serves other modules, be sure to set the status to BAD in the configuration, and let the CALC block set the status to GOOD when it executes and writes a valid value. If you do this, referencing mdules know the value can be used by the GOOD Status.
So what happens on a controller switchover? Which module executes first?
The DeltaV Active controller updates the Standby with changed module data, so on initial execution following a switchover, the modules are already initialized. However, not all parameters are passed. for instance, the alarm XXX_ACT parameters or the AI/FIELD_VAL parameter are calculated every scan, and are internal to the block, usually. If a module references these (and other internal block parameters) from an other module, it is possible on switchover that the referencing module exeuctes first and sees the initial values of these parameters.
BOL provides information on which parameter are not updated by redundant link. The Status of these values should reflect that they have not been derived, so use of status could be used to avoid using the "stale" data. You should avoid using these values and avoid the issue all together.
Note that v10 and v11 have addressed many of these situations, including the _ACT values, which are now updated by the redundancy link, as the HI_HI or LO_LO alarms have need used for interlocks in many configurations. Bottom line, it is important to consider initial execution of modules and to avoid hair triggers on interlocks without including an evaluation of status. If status is BAD this scan, but was good last scan, it is likely the value has not changed. Should you trip on BAD status? Maybe wait a scan or two?
Avoid using the internal parameters of blocks for interlocks so your modules run smoothly through switchover.
For remote references, use the CST and Abort on Read error options in expressions to avoid tripping on a value with a bad status. a Bad CST doesn't mean the process has changed, so trip lock should take this into consideration to avoid spurious trips.
With a DCS, we can create very complex, interacting/interdependent strategies. Error checking is the way to avoid inappropriate action on the part of the strategy. We install redundant controllers for system availability so it is expected that one day, they will come into play. AS such, we need to consider how we've configured the system so we don't trip on values without evaluating if the number is valid or usable.
In the end, the order of execution of modules in DeltaV should not matter. If you think it does, you've likely not configured the system correctly. You cannot control order of execution, so you should avoid the need to do so.
Hi,
I have a question and I think it is somewhat related to this.
Does the data type of my parameters affect controller performance?
For example, if I use 8-bit unsigned integers wherever possible instead of 16-bit (or float), does the free time or free memory on the controller increase?
I know that for example on desktop computers if you have 32-bit operating system and 32-bit CPU, using 16-bit variables does not really bring a benefit.
Thank you,
Istvan
In reply to Abhi: