Recent Control & Safety Systems Discussions
Similar Posts
Deleting a user account from DeltaV system v12.3.1
DV V14: Viewing User Manager account history results in system #U
Logoff DeltaV account using DeltaV live
Service Accounts
Emerson Support Account
Share

DeltaV User Account Specific to P-Cell?

I am looking to limit a service account's permissions to a Process Cell in a specific area. Is this possible, or am I limited to Areas only?

Here is some background: At a site that I maintain, we have a few systems on the corporate network reaching through via OPC to DeltaV:

  1. A Terminal Management System via OPC DA
  2. A SCADA system via OPC DA

Each system has it's own service account, but it must have at least control permissions to read data and write commands. The concern is that someone who is logged into either system could pull up an OPC browser, connect to DeltaV via OPC, and issue rogue commands.

My initial plan to prevent this scenario was to move the data landing zones for each of these systems into their own separate areas and limit the service accounts permissions to that area only. The downside to this plan is that it seems as though I would need to create an area for each system/service account to provide the minimum access possible. Maybe it is just me, but I don't really want to create a bunch of areas just to support this. I would like to create a single area and segregate with P-Cells (for neatness really).

Is this possible? Is there another way to solve the problem?

Thank you,

dave_marshall
  • Andre Dicaire
    DeltaV Security is applied at the Area level and cannot be segregated to the Process Cell level.

    Alarms can be managed at the Unit Level in the workstations, but user access security is applied at the Area level.

    I agree that having an additional layer of granularity would be useful. With the current scheme, users are forced to create additional Plant Areas, which results in the DeltaV Explorer tree no longer following the plant S95/S88 asset structures. If units are to be assigned to different Operators, they must be in different Plant areas.

    For OPC writes to DeltaV parameters, you can enable the logging of these in the DeltaV Event Chronicle. However, this is an OPC Server wide setting. If the OPC server is being used to pull in process data from another source, you do not want an event for every update. But you can use this to your advantage. You would use two OPC servers, one for data integration and one for write access for users. For data integration, all data should land in modules hosted on the OPC DA server's simulated controller. These modules can be in a separate Plant Area and with appropriate security for the incoming data. Users can be denied write access to these modules. On a second OPC server, enable the logging of write events. You will not have the granularity to restrict writes by Process Cell, but you will be recording all parameter changes initiated via OPC, and the user security for the connection will be recorded. This gives you valuable traceability of changes to module parameters.

    I would want to know who is writing to what parameters via the OPC interface. I believe this is documented in BOL. It involves setting a registry setting on the Applicationon station where you would like OPC writes to be logged in the Event Chronicle.

    Andre Dicaire

This is the official online community site of the Emerson Global Users Exchange, a forum for the free exchange of non-proprietary information among the global user community of all Emerson Automation Solution's products and services. Our goal is to improve the efficiency and use of automation systems and solutions employed at members’ facilities by sharing our knowledge, experiences, and application information.

User Groups | World Areas | Community Guidelines | Legal Information | Privacy Policy | Contact Community Manager

Website translation provided by Website Translator

© 2015-2022 Emerson Global Users Exchange. All rights reserved.