I am looking for a bit of help trying to decipher where particular security settings are set specifically with prompts.
I have the scenario where i am issuing a prompt and setting REQDATA1 and REQDATA2 to TRUE, thus requiring confirmation and verification for said prompt.
I understand that REQDATA1 is considered to be the confirm and REQDATA2 to be the verify user identification.
I believe that the user lock ACTION_VERIFY is considered to be a SUPERVISOR key used for prompt verification.
I can't however find any detail explaining where the REQDATA1 and REQDATA2 are set up. How can i show or prove that the REQDATA2 is actually a supervisor requirement to answer the prompt?
Any help would be great.
The REQDATA1-5 and REQUEST work together.
Say you want to send a car to get bananas and Stella from the grocery store. You can do it two ways.
REQUEST = send a car (i.e. 3200)
REQDATA1 = get bananas and Stella (i.e. 1)
REQDATA2 = getting carded to confirm purchase (i.e. 1)
REQDATA3 = friend in the car to verify you got it all (i.e. 1)
REQUEST = send a car to get bananas and Stella (i.e. 3201)
REQDATA1 = getting carded to confirm purchase (i.e. 1)
REQDATA2 = friend in the car to verify you got it all (i.e. 1)
Either way, you're sending a car to get bananas and Stella from the grocery store (i.e. Batch Executive) that'll require getting carded and a friend making sure you got everything. The REQDATA specifics aren't as important as the main objective.
BATCH_ACK_PROMPT is tied to getting carded. Since the person going has the right already to get it, the confirmation is just to verify some 15 y/o didn't get the list (i.e. DeltaV station logged on but someone else in the control room that doesn't have that right to acknowledge prompts is in front of the screen).
BATCH_ACTION_VERIFY is tied to a 15 y/o checking. This action can be the driver as well if that option is enabled, but typically want it to be someone else that is a master at checking bananas and Stella. The verifier might not have the right to do the action, but have a great skill at checking groceries.
BATCH_HOLD, BATCH_STOP, BATCH_RESTART, BATCH_START, etc. are different function security locks. BATCH_ACK_PROMPT is tied to answering prompts through request codes, so the confirmer would have to have BATCH_ACK_PROMPT assigned key. The confirmer for all the other tick boxes would need to have the user key that each action's (i.e. start/hold/restart/abort) functional security lock assignment. The BATCH_ACTION_VERIFY is tied to verifying any actions (i.e. prompts/hold/stop/restart, etc). This could be a supervisor that doesn't have the right to answer prompts/hold/abort batches, but can verify what is going to happen next based on the production schedule.
That's how I usually understand how all that works.
I am not sure I understand exactly what you are looking for but below is a table that I can condensed instead of showing the data for every prompt type.
3xnn - Send Operator Prompt
nn = ID of message
REQDATA1 = confirm enabled (0= False, 1= True)
REQDATA2 = verify enabled (0= False, 1= True)
3x00 - Send Operator Prompt
REQDATA1 = ID of message
REQDATA2 = confirm enabled (0= False, 1= True)
REQDATA3 = verify enabled (0= False, 1= True)"
Your logic would set the appropriate REQDATA parameters from your phase logic and then sets the REQUEST code and wait for the REQUEST to be 0. When REQUEST has been confirmed to be 0 this indicates that the operator has answered the prompt and any confirmation and verification required has been done.
Does this answer your questions?
I appreciate the input.
I am afraid you haven't fully answered my question. I suppose for the example given:
REQDATA2 = True (verify enabled)
How can i know that REQDATA2 will actually be someone with supervisor level access and not just another operator?
Where is it configured or detailed that REQDATA2 is supervisor access level?
I believe the "confirm" has the function security BATCH_ACK_PROMPT which is default "Batch Operate" and the verify is BATCH_ACTION_VERIFY which is default "Batch Operate".
Function security ACTION_VERIFY deals with electronic signatures in batch operate/control studio when it's turned on.
BOL searching "Batch function security" will help you out. REQDATA1-5 are arguments dependent on the request code, and outside finding the information explaining how to use request codes, I don't believe there is a specific document explaining, in detail, the whole mechanism.
Sorry I should have mentioned that the prompts are within PHASE logic.
Do BATCH_ACK_PROMPT, BATCH_ACTION_VERIFY apply to Phase level prompts?
I have read that through the Batch Executive Properties you can set up for confirmation and verification on various actions like START, STOP, HOLD etc and for PROMPTS.
Does BATCH_ACK_PROMPT, BATCH_ACTION_VERIFY refer to the security level for these two tick boxes?
If these tick boxes are applied will it only request confirmation for the prompts i have REQDATA1 and REQDATA2 used or will it apply to all phase prompts?
Currently on the system i am working on Electronic signatures is turned off.
So is the connection between REQDATA2 and BATCH_ACTION_VERIFY just a default or is it configurable?
For some messages though it uses REQDATA3 as verification so it must be used by something somewhere else. Would it be in global variables or buried on some other code that i am not aware of?
Appreciate the analogy :-)
So the actual key associated with the confirm will always be BATCH_ACTION_PROMPT but the REQDATA value is dependent on the actual request being sent.
Similarly the BATCH_ACTION_VERIFY key is associated with verification but the value could be REQDATA2 or REQDATA3 depending if REQDATA1 is a message ID or it's the confirm enabled.
I assume we just have to accept BOL documentation as being the bible when it comes to proving this to other people?
This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Process Management's products and services. Our goal is to improve the efficiency and use of process automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.