Traceability of changes done by DeltaV Excel Add-in

Hi All,

we would like to use the DeltaV Excel Add-in to overwrite the on-line values in the controller. Is there any audit trail to track the changes done via OPC in DeltaV? We would like to "import" thousands of configuration parameters like this and we need somehow to track these changes.

Many thanks,

Adam

  • OPC writes to DeltaV are not audited in the same manner as Operator writes are.  If you had an application writing values from an external system to DeltaV continuously (like OPC Mirror or Datamanager), the audit trail in the Event Chronicle would fill up pretty quickly.  

    I guess the next question is why you need to set thousands of configuration parameters to the running system.  Should these parameters be set in the database rather than on line?  

    I would say you have two options:

    1. Instead of using OPC, use scripting in DeltaV operate to affect your changes.  Using the FRSWriteValue function in Operate will audit the logged in DeltaV user as making the write.  I once scripted a pushbutton in Operate that opened a CSV file, read each line (Module/Parameter.Field, NewValue), and performed the FRSWriteValue for each line of the file.

    2. Have your OPC client trigger a LOGEVENT function in a module calc block whenever it performs other tag writes.   The LOGEVENT can only include a limited number of characters, and a module can only send 5 LOGEVENTs per scan, but the the event will appear in the event chronicle and can contain custom information about the writes being performed.   Perhaps your log event can reference a Work Order number in your CMMS, Change Management,  or other enterprise tracking system.      

  • In reply to Youssef.El-Bahtimy:

    There is a registry setting in DeltaV that disables logging of OPC server writes by default.  The "journalDisabled" key is set to TRUE so that continuous OPC writes don't fill the Event Chronicle.  Setting this key to FALSE enables the logging of all Writes from the OPC Server on that computer.  It also adds the writes to the Upload files so the value can be uploaded into the database.

    In a quick check with OPCWatchit, parameter writes are captured in the event chronicle with the interactive user and workstation node recorded, and the Module upload file also has the values captured.  You have to restart the OPC client to read the key and change behavior.  

    NOTE:  WARNING: CAREFUL:  All OPC clients on the OPC server where this feature is enabled will log all writes.  This is an OPC Server setting, not a client setting.  Do NOT enable this on an OPC Server that is continually writing OPC data into DeltaV modules.  Use a different node (Pro Plus or a different Application station) that only performs on demand writes, such as one time writes from the DeltaV Excel add in.  

    IF you are not comfortable with adjusting the registry key, contact your local representative or Emerson sure service provider and they can assist you.  You can also look into using a Batch file to enable and disable this feature so you don't have to access the registry manually.  

    Andre Dicaire

  • I wish I knew that before! Thanks, Andre
  • In reply to Andre Dicaire:

    Hi Andre,

    many thanks!

    BR

    Adam

  • In reply to Andre Dicaire:

    Hi Andre,

    we got an issue during implementation of your solution. As you said we have to restart the OPC client to read the key and change the behavior based on the value of the registry. We want to log the changes in the event chronicle, but we cannot decide what we have to restart. If we stop/start the DeltaV service, the change is taken into consideration, but we would like to find something more elegant. But as it looks like there is no dedicated service for the event chronicle...

    What we should do exactly regarding this registry change to be taken in account?

  • In reply to Adam Bagosi:

    You should run your client application on a dedicated OPC Server.  The registry key should be set to false and left there.  Any OPC Client using that OPC Server will have writes logged to the Event Chronicle, as if the writes were done from an Operator Station.

    The Pro Plus provides a 250 tag OPC server which could be used for this.  Adding the Excel ADDIN OPC license can increase this OPC server to a maximum of 500 OPC tags.  

    Every Appstation comes with a 250 tag OPC Server, which can scale up to 25000 tags.  If you cannot use any of your existing stations as a dedicated OPC server that logs writes, purchase another App station for this purpose.

    Again, you should not be looking to switch this key on and off.  It is intended as a permanent setting to provide you with an OPC server that logs writes to the Event Chronicle. This is simple and elegant solution that does exactly what you want.  Do not complicate this.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Following your message and other sources of information we understand the following points, please correct or confirm :

    1) The key only exist in the registry of the computer where a DeltaV OPC server is running or can run. This means the Pro+ or any AS

    2) If right this key doesn’t exist on a computer which is a pure OPC client, like e.g. a DV station operator or a station Pro or any non DV computer

    3) When starting only each DeltaV OPC client reads this key on the server with the aim to “know” if an event must be logged or not. This is why changing the key on the server means the clients must be restarted

    4) When any DeltaV OPC client does an OPC write to a DeltaV OPC server which is running on a computer where this key is set to FALSE -> we get a log event

    If we got right these points, we cannot follow your proposal to leave the key set to FALSE on the Pro+ or any AS.

    Because we do NOT want to get a log event for each OPC write from each OPC client wherever the server is (Pro+ or AS).

    We only want to get a log event when a specific Excel Macro using the AddIn is running.

    This is why we thought that changing the key on the server and restarting the DeltaV service on the client before and after using the Excel macro is the right procedure.

    Our system uses OPC strongly as we have multiple OPC connections with external PLC & HMI from package units, with OSI PI, with an ALERT system, etc…

    We want to make sure that we don’t get unexpected log events.

  • The key is for the DeltaV OPC Server (frsopcdv.exe), if set then any write by external OPC clients will cause the DeltaV OPC server to log an event.  Hence the cautious approach to using, it is a global setting for all OPC writes executed on the Deltav node (Pro+, AS, Op Station).
     
    Andre is suggesting you configure a separate DV Node as the target for your application, and enable the log setting on that node.  He is warning you not to use your current Deltav OPC server as all writes will be logged for all of your currently connected clients.
     
    Does that make sense?
     
    From: Adam Bagosi [mailto:[email protected]]
    Sent: Friday, January 31, 2014 11:21 AM
    To: [email protected]
    Subject: RE: [EE365 DeltaV Track] Traceability of changes done by DeltaV Excel Add-in
     

    Following your message and other sources of information we understand the following points, please correct or confirm :

    1) The key only exist in the registry of the computer where a DeltaV OPC server is running or can run. This means the Pro+ or any AS

    2) If right this key doesn’t exist on a computer which is a pure OPC client, like e.g. a DV station operator or a station Pro or any non DV computer

    3) When starting only each DeltaV OPC client reads this key on the server with the aim to “know” if an event must be logged or not. This is why changing the key on the server means the clients must be restarted

    4) When any DeltaV OPC client does an OPC write to a DeltaV OPC server which is running on a computer where this key is set to FALSE -> we get a log event

    If we got right these points, we cannot follow your proposal to leave the key set to FALSE on the Pro+ or any AS.

    Because we do NOT want to get a log event for each OPC write from each OPC client wherever the server is (Pro+ or AS).

    We only want to get a log event when a specific Excel Macro using the AddIn is running.

    This is why we thought that changing the key on the server and restarting the DeltaV service on the client before and after using the Excel macro is the right procedure.

    Our system uses OPC strongly as we have multiple OPC connections with external PLC & HMI from package units, with OSI PI, with an ALERT system, etc…

    We want to make sure that we don’t get unexpected log events.

  • In reply to AdrianOffield:

    Thanks Adrian.  That is correct.  and the key is on every node, but only Pro + and AS allow the OPC Server to run, so it only applies to these nodes.

    Based on the described application, this key will not serve to solve the intended usage.  If there are continuous writes from a client, then DO NOT enable logging on that OPC Server.

    Andre Dicaire