Emerson Exchange 365

• Not Answered

DeltaV batch recipe transitions

Does anyone know if it is possible to lock certain transitions in a batch recipe or remove permission to force,  I want to be able to lock certain ones so the operator cannot disable or force the transition thereby increasing the plant security.

Thanks in advance.

• deltav batch transition transitions

Lee W.

• 2 Nov 2014 4:15 PM
• Cancel

12 Replies

• Robert Rijnders

  

  • 3 Nov 2014 11:48 AM

  Disabling and forcing transitions in running batches all use the BATCH_ACTIVE_STEP_CHANGE function lock. Assigning the key for this lock to a user will allow the operator to force and disable transitions and even perform an active step change in any recipe. So changing these permissions inside 1 recipe isn't possible.
  2 ways to solve this would be. Split the recipes that may not be forced from the normal recipes and link them to a new unit-module in a new area. Then don't assign the Batch_A_S_C key to operators for this area. Seems like a tedious job.
  Other way would be to add 'force flags' with different access-levels to the transitions and assign different 'user locks' to the levels of flags. Then only give senior operators or supervisors the keys to these locks. Also seems like a tedious solution.
  Do operators need to force or disable transitions? Unassigning the Batch_ASC key would be the most simple solution.

  • Cancel
• Richard Dubois

  

  • 3 Nov 2014 1:39 PM

  In reply to Robert Rijnders:

  Hi,
  I think the BATCH_ACTIVE_STEP_CHANGE isn't to force transitions in batch. I will be used for change active step only.
  You can add in your parameter security the FORCE parameter on your specific key. If you add this parameter only the persons have the good righs , can force the transitions.
  Other way is to configure the solution that Robert Rijnders describes with the flags.
  Best regards

  • Cancel
• Robert Rijnders

  

  • 3 Nov 2014 2:06 PM

  In reply to Richard Dubois:

  Refer to Books Online about the batch ASC function lock, search for the 'Batch Functions Security' chapter. We were also suprised that these new batch functionalities (from v.8 and up) were brought under the ASC lock. Since some operators use active step change, we decided to give all operators this key. Forcing and disabling is rarely done in our facility.

  • Cancel
• Youssef.El-Bahtimy

  

  • 3 Nov 2014 2:32 PM

  In reply to Richard Dubois:

  From BOL 12.3.1 Batch functions list (http://www3.emersonprocess.com/systems/support/bol1231/r_batchfunctionslist.html)

  Function Name	What the Function Allows	Default Associated Lock	Is Function Area Specific?
  BATCH_ACTIVE_STEP_CHANGE	access the Active Step Change function. Also allows user to force a recipe transition.	Batch Operate	Yes

  Access to the FORCE parameter controls the ability to force Phase transitions, but does not pertain to recipe transitions. 

  Robert stated it correctly, in that you cannot differentiate the security associated with one transition versus another within the same recipe (only by area).  

  Additionally, operators should generally not have the access to force transitions or perform active step changes, as any other controls you could put in place to restrict access could be overridden.  If you trust them enough to override the fundamental infrastructure of recipe execution, what then should be off limits?

  If there are key transitions areas where they need to be able to force through, then creating a unit/module parameter evaluated by these transitions to allow them to progress and specifically secured for their use would be a solution:

  Transition expression:   (process condition met) OR (ForceTransitionParameter = true)

  where ForceTransitionParameter would be a parameter that is secured and accessible by the operator, specific to the unit, recipe, phase, transition (whatever you need) and is reset to false automatically by module or phase logic.  

  The default shouldn't be that operations can force/disable/ASC, but that certain problematic transitions are identified and have an addressed contingency.

    

  • Cancel
• Richard Dubois

  

  • 4 Nov 2014 6:40 AM

  In reply to Youssef.El-Bahtimy:

  Hi all,
  Actually you are right for the new option of the 'Batch Active change'. I dont' know this one.

  • Cancel
• Youssef.El-Bahtimy

  

  • 4 Nov 2014 11:18 AM

  In reply to Richard Dubois:

  Richard, I also have trouble keeping up with the latest improvements...changes move fast but these forums actually help me in that regard. Keep up the good work.

  • Cancel
• Lee W.

  

  • 4 Nov 2014 12:00 PM

  In reply to Robert Rijnders:

  Thanks very much for the reply, I will try this and all the other approaches mentioned. Our batch system is in its infancy and I am still learning, our recipes have transitions early on that we would prefer our operators not to be able to force, but then later when the resin is taken to a given viscosity then the operator may need to force the transition. I may need to revisit this operation stage and un-assign this ability.

  • Cancel
• MichaelP

  

  • 4 Nov 2014 12:18 PM

  In reply to Lee W.:

  As an alternative to a recipe transition, consider a prompt message to the operator to move on through the recipe. This can be in parallel with any other process conditions you are using.
  Operator replies to a e.g. yes/no prompt and the recipe acts accordingly.

  • Cancel
• Rachelle McWright

  

  • 4 Nov 2014 3:14 PM

  In reply to MichaelP:

  Awesome insights from Robert Rijnders, Richard Dubois, Youssef.El-Bahtimy, and MichaelP. Can any (or all) of you chime in on this #Batch question from member Jack_France? http://community.emerson.com/process/emerson-exchange/operateandmanage/deltav/f/50/t/4382

  Best Regards,

  Rachelle McWright: Business Development Manager, Dynamic Simulation: U.S. Gulf Coast

  • Cancel
• Lee W.

  

  • 4 Nov 2014 7:42 PM

  In reply to Robert Rijnders:

  Hi Robert, the batch asc key is the easiest approach but can you tell me more about 'force flags'? altho a more tedious approach it does seem to be what we want at the moment, the ability to have access levels to only one or two transitions.
  thx.

  • Cancel
• gamella

  

  • 4 Nov 2014 10:09 PM

  In reply to Youssef.El-Bahtimy:

  Other option is to use a report value, generated from phase, on recipe transition. This report can be generated when phase "detects" change in provided unit parameter. User lock associated to that unit parameter provides the security feature required. That parameter may be reset before generating the report value to be sure it's clear when phase is over.
  Same approach may be implemented using operator prompts instead of unit parameter

  • Cancel
• Robert Rijnders

  

  • 4 Nov 2014 11:01 PM

  In reply to Lee W.:

  I also like the suggested alternative with running a operator message phase in parallel. Makes it all very traceable which user confirmed the call.
  Youssef in his first reply gives a short explanation on how to implement the 'force flags' solution. Have a look at that first to see if it is clear, else I can explain tomorrow when I'm back at work.

  • Cancel