Emerson Exchange 365

Add a security lock associated to value of the Alarm / Priority field.

Hi there,

Any insights how to add a "Parameter Security Lock"  to the value of the "Priority" field of an alarm?

(or "Field Security?)

E.g.

In the screen shot below the alarm Priority has a value of "CRITICAL_A".  

In the real world this is a HI HI ALM, with priority "CRITICAL_A" and a limit of, lets say, 95%.

Can I add a Security Lock such that only the "Supervisor" key allows changes to the FacePlate value of HI_HI_ALM with associated Priority of "CRITICAL_A" ?

That is, change 95% to 97% - but only for alarms with priority CRITICAL_A.

Suggest a work around ?

Thanks

MP

• Lock Key Priority Security

MichaelP

• 25 Nov 2015 5:36 PM
• Cancel

3 Replies

• Andre Dicaire

  

  • 26 Nov 2015 6:03 PM

  Parameter and field security is based solely on the name and is not dynamic. It would not be possible to change the security level dynamically on the HI_HI_LIM parameter that is associated with this alarm. In reality, the HI_HI_LIM parameter is unaware with the Priority setting of the associated HI_HI_ALM.
  
  So you cannot do what you propose through standard security settings.
  
  A simple solution is to restrict Alarm Limit tuning such that only certain users can change alarm limits.
  
  Or, you keep what you have but run a report on the Event Chronicle for any alarm limit parameter changes, and make sure limits are not being changed. Emerson has added an Alarm audit tool with v13 to reconcile changes in the runtime alarm system to the settings in the Alarm database.
  
  Finally, you could force certain alarm limits through a second parameter. Changing the alarm limit value directly would have no effect as the forcing parameter value would overwrite it. This could be done by exposing the HI_HI_LIM parameter and wiring an input parameter to that value. Tuning this alarm would be done through this new parameter which would have more restricted privilege. If you wanted to make this dependent on the alarms priority, you could use a CALC block to conditional write to the limit parameter if the priority is CRITICAL.
  
  Using the CALC block approach, you could place this logic in a separate module, (Alarm management Module), and manage all such alarms from this location. This would allow you to deploy without modifying existing modules. The problem with this is that a user tuning the alarm would not be rejected, since the write is successful, but immediately reset.
  
  You could add animation to the detail display that prevents input to alarm limit parameters of Critical alarms. However, changing the limit in Control Studio online would not be prevented.
  
  I prefer simple. Since all writes are recorded, including workstation, user name and time, unauthorized users should know their inappropriate actions are traceable...
  
  Another option could be to create a Signature Policy assigned to those limit parameters that might be Critical. The user would then get a confirmation dialogue that requires user password, and a reason for the change, which would give you additional tracking on those alarm limits. You cannot make this conditional on the alarm priority, but at least, no one can change the alarms without knowing they are making a closely monitored change.
  
  Using priority for deciding if a parameter is "tunable" seems odd to me. Priority is a combination of Time to respond and consequence. A critical process may have longer response times that should place the alarm at a lower priority, even though the consequence is high. Each alarm should be considered on it's specific merits for the alarm system to operate correctly. So, if trusting the users to do the right thing is not viable, I'd go with an Alarm management and explicitly configure an override of the Alarm limit that requires a separate tuning process with special security.
  
  Good luck

  Andre Dicaire

  • Cancel
• MichaelP

  

  • 30 Nov 2015 4:13 PM

  In reply to Andre Dicaire:

  Hello Andre
  
  Thanks for detailed reply. Appreciated.
  Yes, you hit a few nails square on.
  The idea of an over-write is a good one and may be the solution.
  Should it be otherwise and interesting I will get back and inform the group.
  
  regards.

  • Cancel
• Ben Bishop

  

  • 15 Jan 2016 3:00 PM

  In reply to Andre Dicaire:

  I recall a paper presented at Emerson Exchange a few years ago. A user wanted to restrict the disabling of certain super-critical HI_HI alarms. For the reasons mentioned earlier, traditional lock/key security wouldn't work. Their solution was to wrap the frsWriteValue function of the detail display in another function that first checked to see if the current user had the elevated key. Since the solution involves the detail display, it works only when the Supervisor or Operator is restricted to the DeltaV Operate application. Anyone with Control Studio online access and the correct parameter security key can still disable the alarm.
  
  The standard grpPrioOn_Click event code for the AI_dt detail display looks like this:
  
  frswritevalue "0", "DVSYS.@MOD@/HI_HI_ALM.F_ENAB[_NOT_CONFIG_OK_]"
  
  There is a DeltaV Operate parameter associated with THISUSER called USER_CAN which will check to see if the current user has a particular key. If we wrap the frsWriteValue in this function, then we can prevent someone without the key from using the detail display to disable the alarm.
  
  Let's use User Manager to rename one of the user locks to "Critical Disable".
  
  The new grpPrioOn_Click code might look like this:
  
  Dim UserCanDisable As Boolean
  UserCanDisable = frsreadvalue("DVSYS.THISUSER/USER_CAN.B_CV[AREA_A][Critical Disable]")
  If UserCanDisable Then
  frswritevalue "0", "DVSYS.@MOD@/HI_HI_ALM.F_ENAB[_NOT_CONFIG_OK_]"
  Else
  frsMsgBox "Your username does not have the 'Critical Disable' key to disable this alarm.", vbCritical, "Critical Alarm Disable"
  End If
  
  For more information on the USER_CAN parameter see AP-0800-0121"DeltaV Operate Display Parameter Used to Determine if the Current User Has Access to a Particular Security Lock And Plant Area".

  • Cancel