• Not Answered

Deltav OPC Mirror Diagnostics showing "The item’s AccessRights do not allow the operation" error code :C0040006

Dear All,

Deltav Ver. 13.3.6

We are facing a problem with error codes : C0040006(The item’s AccessRights do not allow the operation) in OPC Mirror Diagnostics. we have given all necessary privileges to the user. also we can fetch the data from 3rd party opc server, but the data unable to write in deltav control module. Screen shot is attached for reference. Please help to get the solutions.     

4 Replies

  • Roshan,

    Is your OPC Mirror is running on an Application Station?  If you look at the properties dialog make sure the option "Restrict on-line changes to areas assigned to the Alarms And Event subsystem of this station" is unchecked.  For Application Stations being used for OPC connectivity and batch executive nodes this option should not be checked.  If you make a change you will need to download setup data to that application station.  See the circled item below.

  • In reply to Scott Thompson:

    Dear Scott Thompson,

    Thanks for your reply. We have same setting as you suggested but it wont work.
    Still the problem arises to land the data in DeltaV module.
  • In reply to Roshan Parte:

    There have been some security changes to increase security starting in v13 but I may be getting some of the changes in v14 mixed up. The security hardening of the OPC Server no longer allows users with administrative rights to connect. You can browse with that user as that access is much more restricted, but writes are restricted. Make sure the OPC Mirror service is running under a user that is not a windows administrator and has DeltaV rights to write to the parameters. It might be easier to test by logging into Windows and DeltaV as the same user the OPC Mirror service is running under and attempting to write to the parameter from OPCWatchit.

    Judging by an SMS call the restriction on using a non-Administrator user was added as early as v12.3.1. There is also a note on a v14 system that the domain of the OPC service user in DeltaV User Manager should be set to <Unspecified> but that is v14 so I 'm not sure how relevant that is to your v13.3.6.
  • In reply to Scott Thompson:

    The issue is definitely with user Security with the OPC Mirror User. As Scott suggests, log on with the same user that OPC Mirror uses, and run Watchit. In the Path, enter a parameter path that OPC Mirror writes to. The value should appear with Rt_Success. select the upper left Icon in the dialog to bring up the drop down menu and select "Write Value". In this new dialog, select "May I" which will show you all the user privilege information about the parameter and the current user. The net result should indicate privilege is granted. If not, use this information to determine what level of privilege is locking you out.

    As for "Unspecified" setting in user manager for the account, this allows a User account to successfully log into the computer from any domain or as a local user. In other words, the account name is not bound to a specific domain. It used to be that all DeltaV accounts were "unspecified", which meant that if you created a local account on a computer with the same name as the Domain account, you could hijack the DeltaV account privileges of the domain user. By binding the user to a specific security scope, the DeltaV User is to a specific windows user.

    Setting this as unspecified allows you to create a local account on the Computer (App Station) where the OPC Client is running. User the local computer account, and not the Domain account. You have to create this user manually on the App Station. There need not be a Domain account with the same name. The local account on the App Station would match a local account on the 3rd party OPC server computer, and authentication would be directly machine to machine. For this reason, you want this windows account to have minimum windows privileges and DeltaV privileges.

    Scott mentions that you can disable "restrict On-line changes" for the App Station, allowing OPC Mirror to write to any parameter in the system. Here are a couple of things to consider:
    - OPC Mirror, when used to transfer (integrate) 3rd party data to DeltaV should only write to "landing Modules" assigned to the App Station hosting the OPC DA server. Continuous writes to module parameters located in controllers creates an added medium priority processing thread that consumes Control Thread CPU. Direct writes to Control Modules should be kept to a minimum (< 20 per second at destination). So having the modules in a dedicated Plant Area for Landing Modules, and having them assigned to the App Station makes for a small footprint. It prevents the OPC Client, any OPC Client, from writing inappropriately to DeltaV Modules.
    - The OPC DA server by default does not log parameter writes. We don't want that for data exchange, filling up the Event Chronicle. So the last thing you want is undocumented writes to any parameter in the system, either by accident or by intent.
    - The OPC Client User is known to the Third party system, though the Password should be protected so that they cannot use this account to access DeltaV data via OPC Client. If the password is known, you want to limit the write access that user account has in DeltaV.

    In my opinion, I would not disable the Restrict On-Line Changes option on the App Station and would make sure the OPC Mirror Client is properly restricted to landing Modules via an "OPC AREA" that contains the landing modules. I might use this to open things up at first and get things working, but for deployment in a production system, you should tighten up the write access to prevent unwanted and undocumented parameter changes.

    If you do wish to allow an OPC Client to make changes to control modules, this should be limited to Setpoints and such and should be logged in the Event Chronicle. You should standup a dedicated OPC server for this purpose and set it to log changes. That way, the event chronicle will provide traceability of those changes, which would include the workstation name and User account.

    Andre Dicaire