Ok... this idea is going to be a little challenging to explain. In most industries I know of, different controls can have different 'Criticalities' to them. For example, changing one Setpoint is able to be performed by almost anyone, it isn't a super critical item, but changing another Setpoint should only be performed by very high level people, since it is 'life critical' or has a large impact on the process. I'll give a couple of examples. 1. Water / Waste water... a standard Operator is normally allowed to control certain alarm levels so that they get advised of plant stability. However, they are not allowed to change the setpoints associated with Critical Control Points, these are only adjustable by a Water Quality Manager, or perhaps a Senior Operator under some approved and documented process. 2. Pharmaceutical. A standard Operator may be allowed to change a production line recipe to adjust the consistency of the capsule material (i.e. to dilute / concentrate the lactose coating, or the gel coating), but that same Operator is most certainly not allowed to change the recipe for the dosage of the capsule (i.e. changing it from a 500mg Ibuprofen up to a 1500mg Ibuprofen)... however a Quality Assurance Supervisor may be allowed to deviate the dosage to account for issues with production equipment (i.e. if the weight scale is currently reading low by 15mg/500mg, then it may be possible to trim the dose weight up slightly if additional post-manufacture testing is performed). The current Geo SCADA Expert permissions settings don't provide much handling of this across an entire database. They only provide a single 'Control' permission, and whilst this is adjustable on an Object by Object basis, the maintenance burden with doing such rapidly increases. My proposal is that the permissions themselves could be assigned against a 'Criticality' level, of which there would be a small number (perhaps only 1 as the default, to align with existing behaviour... but allow DB configuration to be changed to increase this). And each object could be assigned a particular 'Criticality' to match. So... for someone like an Operator. The permissions at the top level might allow them to do everything with 'Criticality 3' objects, but they can only view/browse 'Criticality 1' objects. A WQ Manager would be able to do everything with 'Criticality 1' objects, as well as 'Criticality 2' and 'Criticality 3' objects. I'm open to other ways to handle roughly the same concept. Obviously there are 'hacks' / 'workarounds' to get similar behaviour, but not whilst maintaining a sensible database hierarchy. Having an entirely separate branch in the hierarchy dedicate to 'Water Quality' / 'Critical Production Parameters' just adds confusion, and obviously makes the use of sensible templates incredibly difficult. Where there are thousands of water quality sites distributed through the database (i.e. chlorine monitors, pH monitors etc) then using the individual security overrides becomes far too much maintenance hassle, and with so many manual alterations required starts to result in mistakes being made.
... View more
