EE - Forum Styles
fo
  • Not Answered

Is there a way to monitor the redundancy for controller nodes in a system dynamically so it can be used for troubleshooting and diagnostics?

I would like to monitor controller redundancy and create some graphics that will show bad integrity. Is there a way to do this without creating a parameter in a control module with the path "CONTROLLER/REDU/STBY/OINTEG"?

I ask this because we would like to display bad redundancy as more critical than what Deltav displays it as (Maintenance warning level priority).  We feel the redundancy partner not being available is more critical and should be flagged better.  We had a controller go bad, and it was not noticed because that particular controller had other alarms in (bad charm channels, bad vim card) so it was not noticed.

The concern I have is that if I build a bunch of parameters in a control module, anytime we add new nodes (controllers, CIOCS) we will have to add those parameters.  Is there a way to look at all configured nodes redundancy in a calc block expression etc.?  Is there a better way to do what we are trying to accomplish?

Thank you!

Jayme

2 Replies

  • Outside of the Hardware Alerts, there is no way for a control module to automatically detect the additional a node.Control modules need to be configured to read and act on runtime data.  

    In many projects it is standard approach to create a diagnostic module for each node.  Note that some diagnostic parameters are available to workstations but are not available to the controller and some are available to the controller but are flagged during download as unknown paths, but will work.  You can assign these modules to an App Station, and they can be set to 5 seconds or so execution, reducing communication load.

    Since every node is supposed to have a corresponding module, this becomes the place to add a specific alarm like the monitoring of the redundancy availability.  I would suggest a module class based on Dynamic Reference parameters.  Use a CALC block to populate the $REF field based on a NodeName String parameter.  By setting the NodeName to the New Node name, the module will auto define all diagnostic links.  This also addresses issues when referencing a value not defined in the database. 

    There is only one place I know where you can verify what nodes exist in the runtime system.  The Device Table (DT.SCR) file is downloaded to all nodes (check Download folder on any workstation).  DeltaV Operate can be setup with a function to read this file and parse out Node Names, their Type as well as there IP address and Redundancy.   conceivably, if my Diagnostic module is called "PKCTRL_DIAG", I could parse this file and find "PKCTLR" of type PKCTRL, and check to see if this module exists.  If it does not, then flag this. 

    DT

    {

    DTI { NAM='CIOC1-K' TYPE=CIOC ID=306446343 RED=Yes PRI='10.4.0.30' SEC='10.8.0.30' DLE=No RDN=T RCON=F ROPC=F RMIR=F RBEX=F UBT=F }

    DTI { NAM='PKCTLR' TYPE=PKCTRL ID=465371138 RED=Yes PRI='10.4.0.10' SEC='10.8.0.10' DLE=No RDN=F RCON=F ROPC=F RMIR=F RBEX=F UBT=F }

    DTI { NAM='PW1-CIOC1' TYPE=CIOC ID=306446346 RED=Yes PRI='10.4.0.42' SEC='10.8.0.42' DLE=No RDN=T RCON=F ROPC=F RMIR=F RBEX=F UBT=F }

    But maybe simpler is better.  Make sure you have an MOC process that states every new node requires a Diagnostic Module, and create a Class for this that includes the redundancy check.  A quick check of Diagnostic Explorer reveals all the nodes and there should be a "node_DIAG" module defined and downloaded.  When you add a controller, this is the first module added as part of the MOC. 

    Note that all configured alarms also show up in the Alarm Management app and as an alarm, all should be vetted with a required action and time to respond.  The Alarm MOC should also ensure you've set up the alarm properly.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Wow, very good information! Thank you Andre, I will definitely get all of this added to our MOC process when adding new nodes.