How to generate alarm when user changes configuration database?

Does anyone know how to raise alarm when user changes DeltaV configuration database? One of our clients is requesting this feature.

  • The first question is, What will the operator do when this configuration changed alarm?

    Alarms should indicate an action for 'someone' to do and this doesn't seem like it would be an operators jobs to worry about this.

    I would push back on the client and ask who this requirement is for, It might be covered by the Blue Triangle indication on the nodes in DeltaV Explorer when a download is needed.
  • In reply to Matt Stoner:

    Hello Matt,
    Long time, No see. The client is asking this functionality as a part of Configuration Audit Trail. If I understand correctly, Version Control captures configuration changes for particular database only. In addition, please note that this query is pushed by their Cyber Securit department. They are thinking of the scenario where malicious person hack into their system and change their database or one of their engineers switched configuration by himself and didn't notice his manager. I see your point. If generating alarm is not appropriate, can we at least log this event in Event Viewer?
  • You cannot generate an alarm when a user changes configuration in the database.  Database changes do affect the running process until a download is performed, so they do not have relevance to the alarm system, nor should they.  An alarm is for operators and should only be configured if a response is expected by the operator to resolve a process condition problem.

    If you want to know when changes are downloaded, I would suggest having a reporting tool that indicates when downloads are performed by looking at the event chronicle.

    You can set up a process history view event file with filtering to report that information. You could also potentially use an OPC A&E client like Plant Messenger, to subscribe to download events and email/text you when an event is detected.

    If you wish to control database changes, I would start with security.  Make sure only those allowed to make database changes have the priviliges to do so; that means everyone doesn't log in or know the administrator password, but uses their own dedicated account that they are responsible for. 

    Next, try enabling Version Control Audit trail. It will record all changes and enforce check in and check out. You can generate a report of all changes by date to determine when someone has made a change.

  • In reply to tasai:

    A hacker probably won't change the database, but rather make an online control parameter change. In the case of stuxnet, a virus made subtle changes to running parameters over time.
    A periodic review of the event chronicle should be sufficient to identify runtime changes made through user interfaces. Virus protection should also be enabled, and the DeltaVAdmin password should be changed from the default, firewalls should be employed, etc. to prevent automated attacks.
    There are several whitepapers on DeltaV Cyber security. Take a look and see if this satisfies your inquiry.
    http://www2.emersonprocess.com/siteadmincenter/PM%20DeltaV%20Documents/Whitepapers/WP_BestPrac_CyberSec.pdf
  • In reply to Youssef.El-Bahtimy:

    Youssef, how does Version Control behave if user changes configuration database? Will you notice a new module suddenly appears and/or some modules disappear from database?
  • In reply to Youssef.El-Bahtimy:

    That Cyber Security document you mentioned as well as all your suggestions listed here are already provided to this customer. They came up this question after we explained all these featuures.
  • In reply to tasai:

    Version Control (or VCAT) works like a library-system. You have to 'check-out' an item first before you're allowed to edit it.
    After enabling VCAT, every object in the control database gets a version history. When you're finished editing an object and want to download, DeltaV will ask if you want to 'check-in' the item before downloading. On check-in the user needs to fill in a reason the object was modified. The version is then increased and time-date and user information is stored in the VCAT database. In the version history different version can be compared to see the differences.
    VCAT has the option to generate a report between selected dates. In this report, all changed objects are listed. So new items and deleted items. Deleted items can also be restored using VCAT.

    Generating alarms from VCAT isn't possible for configuration changes. Seems like an odd request from your customer imo. Tracking the alarms&events database would be the only option to warn the operator for downloads on the system.
  • In reply to Robert Rijnders:

    Robert, thanks for explanation. I know VCAT compares the different version of modules, assuming you didn't change DeltaV configuration database. How does VCAT behave if you change configuration database from DeltaV Database Admin? Does VCAT recognize that database has completely changed? If so, does that event get recorded somewhere?