Then plant is running 800xA 5.0 SP2 Rev.C with AC800M and DCI.
We added a new operator workstation in a new plant area. Let's called it "Area Z".
The manager would like to change operator permission for this new computer because it's not located in the main control rooom.
-On this new computer, operators must have operate permission only for graphic displays related to Area Z.
-On this new computer, operators must have read only permission for other areas graphic display.
-Area Z operators are the same as main control room. So, it's not possible to create new rule based on new operator names. We must use existing operators.
What we tried:
-We tried to deny all operate permissions for operators for this computer by adding this deny rule into admin structure security definition.
-We then allowed operate permission for operators on the Area Z graphic displays with "Terminate search" set.
Problem: it does not work. Operators could not operate Area Z graphic displays. It looks like 800xA does not check permissions in Functional Structure for those objects. We thought it would because objects are in the graphic display and Functional Structure is the first to be evaluated. It looks like we should set permissions on objects in Control Structure. We tried to do it with Functional Structure because there were less security definitions to create, manage and maintain.
What security strategy would you use to achieve manager specifications?
Should we keep the general deny operate for this new computer and allow operate for Area Z objects directly in Control Structure? What do you suggest?
Voted best answer
Firstly, Run a security report. The "search" may be terminating before it reaches the security definitions in the functional structure. Also, check the search order. From memory I think by default the functional structure comes after the object type and control structures. You can change the order depending on your needs.
Next, remember that security definitions work on objects - but graphic displays are aspects. So, if you want to restrict access to the objects (like valves, motors, pids etc) on a graphic then you have to make sure that the graphic display is an aspect of whatever parent ( eg application or program ) the objects belong to. The security definition is then placed on this object and applied to the object and descendants
Finally, the functional structure often only has the top level objects. If these objects are also in the control structure, then this is not a problem, because your security definitions exist in both structures. But if your Functional Structure only has "placeholder" objects for the graphic displays, then the security definition aspects can't work - they dont know what objects are included in your graphics, they only look for objects in a structure.
Do you use individual operator Logins for each operator or a general operator Login in the Main Control Room? My suggestion would be to create new Operator(s) for the "New Area Z" which will allow you the most flexibility for setting up the Security Definition Aspects either in Functional or Control Structure. You could also set up a specific Workplace for that Area which would also help with the Process Sectioning you are hoping to achieve. If using individual Operators just copy those and then add a Prefix or Suffix to username for "New Area" designation when those operators go to the "New Area" to work. Even easier if you are just using a general operator login.