Re: [foxboro] Philosophy of operator action Protection ID's
- From: Kevin FitzGerrell <fitzgerrell@xxxxxxxxxxxxxxx>
- To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
- Date: Wed, 22 Mar 2006 14:58:10 +1200 (NZST)
Alan,
I've worked with a variety schemes for this.
My favorite is what I think you are describing -- an access class for each plant
area. An example of this might be:
01 - general
02 - safety
10 - crushing
12 - overland conveying and stockpile
13 - grind floor
14 - gravity circuit
15 - thickening
20 - screening
21 - leach
22 - CIP
24 - detox
31 - reagents
32 - air system
33 - water system
41 - regeneration
100 - engineering
So, if an operator is responsible for crushing/conveying/stockpile, he logs in
to his environment that has access levels 01, 10, 12. Another operator whose
tasks have some overlap may get 01, 12, 13, 15 and 33. A third may get 15, 20,
21, 22, 24 and 32. Engineering gets all except 02.
The best part of this scheme is flexibility. If operations restructures the
operator duties, all you have to do is redistribute the access class permissions
in the .acl files.
It's fairly easy to migrate from a broader scheme to this, by including the most
logical access class from the old scheme to each operator's environment.
We've avoided making this match our area numbering because our area numbering
didn't mesh well with Foxboro's limits on ACL numbering. Also, this preserves
the ability to split a plant area into two access classes.
The biggest challanges I've seen with this system have been:
1) People copying bits from one graphic to another and not modifying all the
access protections is an issue.
2) If access classes are defined too narrowly, how do you handle multiple
operators in a control room who cover each other's plant areas when one steps
out for a few minutes? We ended up merging a few previously separate
environments for this reason.
3) Carefully consider start stop access. In some cases we're assigning a
general acl for stop actions, so a motor can be stopped by any operator who has
it on their graphics, but protecting the start action with the plant area access
class.
Regards,
Kevin FitzGerrell
Carter Holt Harvey, Ltd.
+64 27 460 9994
Quoting "Adam.Pemberton@xxxxxxxxxxxx" <Adam.Pemberton@xxxxxxxxxxxx>:
> Hello all.
>
> I have been having a debate on the use of Protection ID's with a couple
> of patient Invensys people and have come to a bit of an impasse. Hence
> I
> would like to open the debate to you fine people on this wonderful
> forum. Here is my (slightly edited) original question:
> ------------------------
> As we are working on FoxView at the moment, I've been examining our use
> of Protection ID's and it's not particularly imaginative. We are only
> using ID's 130 to 135 and the two biggest areas in the plant, Grinding
> and Autoclaves, share the same ID.
> Hence I'm thinking of migrating to a new system (some 65 Protection
> ID's
> directly related to the existing Site Area Number system). I see this
> as
> being an evolutionary change with us using the new ID's for new pages
> and for any pages we happen to be editing. I figure that it is trivial
> to specify the IDs in the .act environment files for access control.
>
> My question is, do you see any downside of this approach and any
> potential pot-holes?
> ------------------------
>
> As a supplementary comment, one of the areas of debate are to do with
> whether Protection ID's should be considered as "Access Levels" or
> "Area
> ID's".
> I also posed the problem of how to deal with a situation where we need
> to specify special control for some common items.
> For example our "Plant Air" and "Plant Water". I.e Grinding and
> Autoclave controllers should be able to manipulate the air system and
> water, but Power Station controllers should only control water. Also
> there is some areas of overlap between Grinding and Autoclaves that
> both
> operators need to control (Grinding Thickeners and Pre-oxidation
> tanks).
> Finally the above system is complicated by the fact that the rules can
> change with operating philosophy, personnel etc.
>
> Regards
> Adam Pemberton
> Coordinator Process Control
> Lihir Gold Limited
>
> Ph: +675 9865 655
> Fax: +675 9865 666
> Mob: Nogat
> Postal:
> Australia: GPO Box 905, Brisbane, QLD 4001
> PNG: PO Box 789, Port Moresby, NCD
>
>
>
>
>
>
>
> ______________________________________________________________________
> _
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>
> foxboro mailing list: //www.freelists.org/list/foxboro
> to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
>
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
