Does anyone know if there's a possibility to transfer the alarms of equipement (EM's and CM's) to another workstation (same network, but logged in by a different user). For example a tank including equipment should be transferred from one operator to another (the operators are two different users) If operator1/user1 transfers equipement it should only be possible to control the equipment by operator2/user2. But also the alarms should only be visible for operator2/user 2, till operator2 is finished with the equipment and decides to hand over the control to operator1/user 1.
Background information
On this plant there are two different companies, that share equipment. Sometimes a tank and its equipment is managed by an operator from company 1 and vice versa. If the tank is controlled by company 1, the other company doesn't need to react to the alarms.
You can change how a workstation handles alarms by module, area, or user using the ALARMS parameter. From your description (here and on LinkedIn - I replied there also) I'd think that you could use the user ALARMS parameter and the .PRI field - changing the value in the Equipment Module code - to implement the effect for what you are requesting by changing the priority of the alarms for one user to cause it to be Log Only and for the other user to be as configured. Look into the "Events and Alarms Reference" article in Books On Line to find the "THISUSER ALARMS Parameter Fields" sub-section for more information.
Hope this helps!
In reply to JDWheelis:
Alarm assignement in DeltaV is done by Plant Area. The shared resource needs to be in its own Plant Area.
In addition, the logged on User must also be given privilege to control the Plant Area to be able to see the Alarms and acknowledge them. This level of privilege is not dynamic. You cannot add or remove the ability to control/acknowledge alarms once assigned.
However, in each console, you can hide Plant areas from view, which will remove the alarms from that area from the Alarm Banner and Alarm List. There is a default display provided where users can manually enable or disable a plant area, and also by Unit within a plant area.
So I would create an Owner parameter for this tank, whereby setting this to one company or the other provides a trigger for a script in each console to enable or disable this plant area. For instance, if the the parameter says COMPANY A, then the script in COMPANY B consoles triggers and disables the Plant Area. The consolse in company A also trigger and enable the area. I would also add a Feed Back parameter to capture the alarm state in the other system so that the Area cannot be disabled unless it is monitored by the other company. Company B console would not Disable the area until Company A console confirmed it was monitoring the area. (make before break logic).
Whatever mechanism is being used to set ownership of the Tank would add code to set this ownership parameter (if it does not exist already). Use a periodic check as well as On Change triggers to create the required logic with ongoing checks incase things get out of sync somehow.
if there are multiple consoles involved, you'll have to consider how to provide the feed back, but I'd do an exception check in each console to determine if they need to write to the feedback parameter. If it already is set to Disable or Enable, then some one has already done the deed.
Only consoles/users that have the Plant Area Assigned should participate in this check. You can create a global variable in your user project and set this from the USer Settings file specific to each console, Note that the Parameters you create should be in a module assigned to this area. IF a user does not have privilege to write to these parameters, they won't have the alarms anyway. Kind of self healing.
I"m not sure, but I think the .PRI parameter mentioned by JDWheelis is actually in the controller at the source. the ALARM parameter allows you to manage the alarm in context to the module, unit or plant area, but maniplulating the priority of the alarm means setting it in the controller, not the workstation. I don't think that would work. I haven't had time to confirm.
Andre Dicaire
In reply to Andre Dicaire:
The suggestions provided by Andre are all excellent, and can be used or implemented in conjunction with the use of the .PRI field of the ALARMS parameter. The information to which I referred in BOL describes that field and parameter well, though that article doesn't state the ALARMS parameter is a workstation parameter as clearly as the help file for DeltaV Operate does. You can find that information in Configure mode of DeltaV Operate by selecting the Datalink button in the DeltaV Toolbox, selecting the DeltaV Browser button to the right of the Source field (with ... on it), then selecting the "Help on Display Parameters" button to get the "DeltaV Operate Display Parameters" help window. One of the links on that window is "THISUSER Workstation Parameters"; select it to get the "THISUSER Workstation Parameters" help file. This file starts with "Each workstation maintains a prioritized list of the 250 highest priority alarms for the currently logged on user." and continues a bit later with "The following workstation parameters are referenced using THISUSER (for example, THISUSER/ALARMS[1].LAALM."
This makes it clear that the ALARMS parameter used as THISUSER/ ALARMS.PRI will provide the ability to change the priority of the alarms being maintained by that workstation for the currently logged on user, and not change the priority of the alarms for any other user on any other workstation. This is why Andre's suggestions to create a coordination method between workstations would also be needed.
An addition to my previous post that I didn't realize was needed at that time involves the possibility that the equipment module in the controller may not have access to the THISUSER/ALARMS parameter (could be checked by creating an expression to test it). The code to deal with changing that parameter's .PRI field may need to be located in the workstation, and coordinate with the equipment module - if needed - through the workstation code checking parameters in the equipment module. The specifics of the method to implement the code in the workstation could involve VBA in the workstation, or possibly another method of creating workstation-based code. I am not the VBA expert that would be needed to to provide guidance on that part, so I will defer to someone else's expertise on that topic.
After a bit of testing, I'd say your best bet is to use the Unit Filtering(you mention else where you have 300 units). You would enable or disible filtering in a console based on who owns the unit. WIth the unit filtered, its alarms will not appear in the Alarm banner or the Alarm Lists. You need mechanism to identify who owns each unit, such as a parameter in that Unit Module, and the CM's need to be assigned under a Unit Module. Not sure if you need Unit alarm Management license if the units are not Class Based.
You can then create a VB function to monitor the owner of the unit, and dynamically filter the Unit as needed. I'd suggest starting with a manual solution and evolving it. Always keep a manual override or a disable key until all use cases are addressed and the mechanism is reliable/robust (auto corrects).
Hiding the alarms does not remove the ability of operators to manipulate module parameter on a filtered Unit. To avoid accidental operation of a unit, you might want to add conditional presentation in your operator displays to clearly show who owns the unit and even hide SP, MODE or OUT parameters.
Hiding alarms automatically poses risks, and you must be sure you can't get into a situation where no operator has visibility of a Unit because of this feature. What are the risks and consequences. Only you can determine the level of checks you need to ensure proper operation. But Unit Filtering is the mechanism to focus operators on the alarm scope they are responsible for when it is a subset of all the assigned plant areas.
Through continued investigation and testing – suggested off-line by Andre – I have a few updates to my previous discussion.
For the method that I originally mentioned – using the .PRI field of the ALARMS parameter for the current user logged on – the field I really meant to mention is the .PRIAD field, which is only available on the module ALARMS parameter, and not on the Area or THISUSER versions of the ALARMS parameter.
This means that using the .PRIAD field of the module level ALARMS parameter is not likely to provide the effect you are looking for. I am currently not able to test it, but changing the .PRIAD field will change the priority of the alarm for the module in the controller, which should then be communicated to all the workstations with that plant area assigned.
This leaves two possible methods for implementing the effect you have requested of “transferring alarms” between user/workstation combinations.
In the first method, you could use a unit module for consolidating the alarms on the tank – to make it easier to change how the unit module processes the alarms of the control modules assigned to the unit.
The same help file I mentioned before includes a section on the “Unit Workstation Parameters”, which has a UFILT parameter that can be used to turn off the unit alarm processing. The parameter path (in DeltaV Operate) is DVSYS.U$/unitname/UFILT.F_CV. Setting this to a 0 filters the unit’s alarm handling, effectively turning off that unit’s alarms on that workstation.
This method could mean that the operator will see a different method of getting access to the information on the alarms than what he used previously, by needing to go through the Unit module’s faceplate to get to the control module’s alarm details.
The second method is what Andre originally described, in which the control modules associated with this equipment are all assigned to a plant area. Then the alarms for a workstation can be filtered, or turned off, either manually by the operator on the Area Filter display in DeltaV Operate, or through code by changing the area’s workstation parameter AREAFILT to 0. The parameter to use for this would be BASE_TANK_AREA/AREAFILT.CV.
As Andre has since posted and because the number of tanks for which you are needing to selectively provide alarms to the two companies exceeds the number of plant areas possible, the method that would make sense in your situation would be to filter by unit modules.
And the additional suggestions in Andre’s last post are all excellent, and should be considered in your development effort.
Bottom line – it’s feasible, using one of two methods to implement the request; one involves changing the operator’s method of getting to the actual alarm itself (through the unit module faceplate), and the other leverages the filtering by plant area (with the possible override by the operator).