Emerson Exchange 365

• Not Answered

Field/Parameter Security and Simulate

I have a system where the FIELD security for ENABLE is Restricted Control and SVALUE is System Admin (I believe SVALUE is out of the box set for Restricted Control).

The result is that supervisors, who have Restricted control and not System Admin, can enable simulation on AI, AO, DI, DO, DC, PID blocks, but can't actually change the simulation value, regardless of what is setup for parameter security.

My opinion is it should be all or nothing, as enabling simulation without being able to set the value is probably just as bad as setting a value if you aren't suppose to.  If supervisors shouldn't be able to simulate a value, so be it.

Not sure what the history of the system was to have created this situation, but my options are to

1. pretend I didn't see it...

2. change ENABLE to System Admin.

3. change SVALUE back to Restricted Control.

4. Take user interface for simulate parameters away.

I checked the books online article 'DeltaV Parameters Types and Field Definitions' (which appears in the OPC section, so it took some time for me to find it) to see what types of parameters use ENABLE, as I am leaning in that direction, and it only shows simulate type parameters for both discrete and floats.  Provided there is no where in the system where a supervisor would need to enable a simulate (like as some sort clugy switch between an I/O and  value wired into the SIMULATE_IN parameter, I hope not) then I should be good to make this change.  

Anything I'm missing? Thanks.

Youssef.El-Bahtimy

• 19 Oct 2017 8:23 PM
• Cancel

4 Replies

• MCrisler

  

  • 19 Oct 2017 9:03 PM

  The type/field definitions listed in the OPC section I think are just restricted to what you can pull over the OPC connection. There's another BoL article, 'Function Blocks - General Information' (Under Configuration->Function Blocks) that seems to have the full list near the bottom of the article. From that it looks like it agrees that ENABLE is only for simulation float/discretes.

  • Cancel
• David Tudor Evans

  

  • 20 Oct 2017 2:56 AM

  I am coming back to OPC after a lengthy absence. Is it still the case that OPC cannot be used for control signals, such as to a control valve?

  • Cancel
• Youssef.El-Bahtimy

  

  • 20 Oct 2017 5:07 PM

  In reply to MCrisler:

  thanks, I was looking for that one. I also wondered if removing the specification of ENABLE from field lock definition would then allow deferral to parameter, which would be just SIMULATE and SIMULATE_D, as no other parameters can even have an ENABLE field, but this would probably be just as effective as just changing ENABLE and would have identical potential risks.

  • Cancel
• Youssef.El-Bahtimy

  

  • 20 Oct 2017 5:16 PM

  In reply to David Tudor Evans:

  I suppose it depends on criticality and reliability. If you are using a single OPC client to control the valve over a single OPC server, I wouldn't recommend it. If you have redundant automatic failover OPC clients controlling over a redundant network to a redundant automatic failover OPC server pair, maybe, provided the criticality of controlling that valve could tolerate a disruption and/or fail appropriately. My first company out of college use to implement OPC based advanced control, where the OPC connection was for supervisory cascade setpoint calculation, but the final control element was still regulated by the subordinate controls. The OPC connection failure would trigger a shed from CAS to AUTO in the final control element PID.

  • Cancel