Emerson Exchange 365

I get a logon logoff event in my chronicle and we didn't do anything custom

In reply to Jason.Brumfield:

Do you have OPC client(s) in use in your system? (OPC Classic/OPC.Net)

Chip, what is your use case? As Jason mentioned, you will get an event logged in the event chronicle.
If you are just tracking, that should provide a means of capturing.
if you want some action on the station, that might require some scripting.

In reply to Lun.Raznik:

Yes but I'm not following how this is related to user login tracking. Do you need to track if an OPC connection changes user accounts?

Chip, actually the controller logic is not aware of when a user logs in or out so no module can do this. As stated below, Operate's scheduler can perform a task when a trigger is detected such as the 'DVSYS.THISUSER/USERNAME.A_CV'. This will be triggered on every workstation each time a user changes unless of course you write some exceptional logic in the VBA. I think a few of us are curious about what you would like to have happen when the user changes. As others have stated, the chronicle does record log in and out, but I suspect you want to take an action within the control application on change.

In reply to Youssef.El-Bahtimy:

I believe there are logon/logoff events recorded when a user launches or closes a DeltaV application that connects to the database. an actual user logon/off records the user name, but thes background appear without details. I have not tested this, but it explains what I've observed.

I use RDP sessions almost exclusively so I haven't compared a physical Win10 thick client vs an RDS session.

Andre Dicaire

In reply to Andre Dicaire:

Sorry for my late response - I didn't anticipate the interest this question would garner.
Building the event in the scheduler based on "DVSYS.THISUSER/USERNAME.A_CV" is definitely the best path forward for me as I need to execute some VBA whenever a new DeltaV user logs in.

Specifically the idea is to filter alarm areas on a per operator and a per workstation basis. The user change event fires a function that reads a csv file that is unique to each workstation and then writes an alarm filtering bit for each of the areas in the plant. This is based on the path:

dvsys.THISUSER/AREAFILT[area_index].F_CV where 0 is AREA_A and each of the rest of the plant areas have been assigned a unique ID. This is the same path that datalinks in the out of the box alarm filtering graphic are based on.

Something that I learned in development is that if a targeted area is not assigned to a workstation the value for that area-filter in the DVSYS server will be a -1 and if you try to enable alarms for that area operate will throw an error with a message box. So you have to check to make sure an area is not disabled before attempting to filter alarms from said area.

The csv file we built to hold the alarming requirements is a table of users and plant areas and a binary value for whether a particular user should receive alarms for an area on that workstation. I'm not sure how maintainable this is in the long because:

Plant areas added to the system would require a new column to be added to each of the csv files. Area deletions would be an issue as well

I don't know how portable this will be going into DV Live as I'm not very familiar with the TypeScript capabilities

Hope these ideas are helpful to someone in the future

Chip

In reply to chip.burge:

Chip,

Out of the box, DeltaV takes the user Area assignments and the Workstation Area Assignments to filter only the alarms permitted by both. If yo don't assign the Area to the user, they do not see alarms in their Alarm Banner and are prevented from acknowledging or changing parameters in modules from that Area. If the Workstation is not assigned an Area, nobody can see alarms or take action on modules in that Area.

Alarm Filtering is another layer that allows the user to focus on a subset of his assigned areas, and filters out that area from his alarm banner and alarm list, but still allows them to write to module parameters in that filtered Area. You can also filter by Unit.

So the difference is that filtering can be turned on and off on a given station by a user. My question is why are you looking to use Filtering rather than using the Assigned Area feature of Users and Workstations?

As for DeltaV Live, it uses TypeScript for custom functions. It does not have access to files on the workstation hard disk, so it would not be able to read a .CSV file to parse information as is possible in Operate VBA. Live also does not have a Scheduler. Instead users can create Variables with OnWrite enabled, which is similar to OnDataChange in VB. I'm thinking a Script based function could be created for each Workstation with filter settings for each user. Then you pick the current user and set filters. Each function is adjusted per workstation. Not pretty. But given the XML format, you could have an Excel Sheet generate the XML files to import so you could manage this in a spreadsheet.

Or do you really need this auto filtering if you set User and Workstation span of control

Andre Dicaire

In reply to Andre Dicaire:

I think the situation is that some operators have more knowledge of the plant than others and are given more responsibility than others. I'm probably oversimplifying here but that was the gist of it.

My job was just to sandbox and figure out if it was possible not to decide whether it should be done

In reply to chip.burge:

Since you can assign different levels of privilege (permission to change types of parameters) and you can restrict a user's access to fewer Plant Areas, and you can set span of control of workstations so that certain control actions must be performed from specific consoles, are you able to get users their requisite access with these tools? And if not, can you give us an example of why you need to automate the alarm filtering per user/workstation?

Andre Dicaire

I have this same scenario with one of my customers. In this particular case the plant is divided into two sections and the control room has two sets of operators to match. While some areas are segregated by user and operator station, there are some overlapping areas that both operator sets want to have control over, but only the side who has primary responsibility over the equipment needs to have the alarms report to them.

The idea here is that the other sides' operators can help support in either a plant upset or an emergency.

I've been trying to figure out how to automate the alarm filtering on a per-operator station basis and you just gave me the path forward. Thank you!

As to the long term maintainability of this, I think an editor could be built in the HMI system itself. While not perfect, it would give someone an easier way to maintain this functionality.