Emerson Exchange 365

• Not Answered

Unique variables to verify controller

Hello all.  I am trying to build a verifier to make sure that certain control modules are running on a specific controller.  Let's suppose this controller is called CTRL-01. What is the best parameter to pull from CTRL-01 during online operation to accomplish this?

The parameter pulled should also be robust to when we swap out the physical controller in case of breakage, and should also work when the redundant pair kicks in.

Thanks!

• verification
• parameters

DeltaVUser8

• 19 Jun 2020 4:03 PM
• Cancel

4 Replies

• Lun.Raznik

  

  • 19 Jun 2020 4:22 PM

  The modules are not aware where they are running.
  
  Reading certain files in the ProPlus may give you a pretty good idea where it is running:
  1. Walk the files in <ProPlus>\DvData\PowerUp\, you have to do recursive search here. Say, I have a module called MYMOD, it will be called _MYMOD.CM.
  2. Once you have found the module, read STARTDEV.STE on that same directory. The 4th line will tell you the controller.
  
  Just curious, what is your use case?

  • Cancel
• DeltaVUser8

  

  • 19 Jun 2020 4:46 PM

  In reply to Lun.Raznik:

  Thanks for the reply! This will be used as one step to protect some of our proprietary solutions that we've developed in house. We will deploy it onto one controller, and do not want the end user to copy it to other places in the site. In putting these measures in place, we want to make sure it is only ran on one specific controller.
  
  I was able to find STARTDEV.STE in the directory, is there a way to continuously pull this value into DeltaV as an input parameter in a control module?

  • Cancel
• Lun.Raznik

  

  • 19 Jun 2020 4:54 PM

  In reply to DeltaVUser8:

  Is this a skid solution then, yes?
  
  I am not sure if this can written directly to an Input Parameter without external application.
  
  But since you need to have a parser somewhere running you can use OPC to write into it. If you have DeltaV Operate as part of the solution, you can also write a "Schedule" to periodically update the parameter.

  • Cancel
• Andre Dicaire

  

  • 22 Jun 2020 9:43 PM

  In reply to Lun.Raznik:

  Your goal appears to for the module to verify it is running on a specific controller. That cannot be done in DeltaV.
  
  DeltaV does not run like that. It would be nice to have some reserved parameters like "MY_MODULE_NAME", "MY_CONTROLLER" so that a control module could be "self aware". (Sounds ominous). But we don't have that. And although you can read the MAC address of the controller, The module could be anywhere and it would still read the specified controller information.
  
  The MODT.SCR (Module Table) is a text file that will give you module location. This would let you know if the module was reassigned to a new controller, but if it was renamed, you would not now what to check for.
  
  You could simply generate a Log event once a day from your locked code, call it a license validation message. The record will automatically include the module name, the node it is running on and the description field will hold what ever you place in that event logic. If you then parse the Event Chronicle for entries where the Description field includes "Validation Message", you could include the Module and Controller name in the message, and compare this to the controller and module names in the entry. If these don't match, the module has been moved or has been copied and renamed.
  
  This could be defeated if the module is placed in a Plant Area that is not assigned to the Chronicle. If the module is copied and added to such a plant area, there would be no message. However, the module would not record any alarms either, or user change events or anything.

  Andre Dicaire

  • Cancel