How to indicate node status in graphics
I want to indicate following status of a node in graphics. How do I do it?
- Node shutdown
- Node UP
- Primary network Down
- Secondary network Down.
I know these exist in RNRP window. but how to represent this in graphics?
Voted best answer
The new feature of feature pack-4 is for controller hardware status only and not for node status.
In your case, You can use PNSM (geniric computer node object) but be aware that it will have very high scan time ( by default 1 minute ) and will wait for 3 cycles before it throws out a message telling node is down.
So you may need to wait for 3 minutes for status to update. You can reduce this scan time though but at a cost of high network load.
The only feature is to use PNSM objects and take the property from IT control connection aspect thru which you can display th up/down of PC status in Graphics display. Pls refer the snapshot for more info. However Network up and down you can see only from RNRP status monitor, It is not possible to bring in Graphics display as there is no OPC property for RNRP stauts.
There is also possible to deploy network management software for monitoring of industrial networks. This solution map all (also behind routers) and can completely monitor network. Solution represents graphical status representation for devices, links, power supplies, fans, and any other device sub-component. status displays for third party products. All statuses are configurable. Supports multiple topology windows and a network hierarchy view. User configurable event log and so on with customisable event actions.
SCADA /Process visualisation
OPC Server Map device and connection states as well as device properties. Can be used inside SCADA systems via the OPC Data Access 2.0/3.0 interface. ActiveX Control Graphical User Interface can be reused inside SCADA systems via an ActiveX control.
Example for supported protocols: ICMP(ping), SNMPv1, SNMPv3, OPC DA 2.0/3.0.
I am surprised why there is not native interface to DCS via any supported protocols above for basic network status monitoring (in case of DCS SNMP protocol support there is not necessary to have any other SW or OPC - direct reading statuses from network devices).
RNRP does not have any OPC DA interface.
PNSM can be somewhat used. However, its node up/down status is based on a rather slow poll via WMI and can not be used to derive individual status of the primary or secondary network.
But since the RNRP node status is converted into alarms by the System Status service (running in Aspect Server nodes) you can use the Alarm Conditions aspect to convert alarm status into OPC DA properties.
The Alarm Conditions aspect exposes some OPC properties for each alarm condition known to exist or have existed on any given object it is created on.
I don't think you are able to distinguish between primary and secondary network, but you can at least treat the alarm priority level which is "1" for all networks down (=node unreachable) and "2" for "one network down" (=node reachable via at least one network).
Remember that the RNRP alarm status is calculated by the System Alarm service in one of the aspect server nodes, not the RNRP service in the local node. I.e. the status indicated is viewed from "a central" not local point in the network.
To tell whether a node is "up" or not is more difficult - one way would be to utilize PNSM IT Device aspect and "Computer Process Status" to read the Process ID (PID) of some process known to exist when the node is "up". The process name might have to be adjusted depending on node type.
Note: using PNSM IT Devices also requires a AO_NET_MON license seat.
When the monitored process is NOT running, the PID property will become "bad" which an alarm expression can not handle. To work around this, you can configure a Property Transfer to write the PID to a General Property and to substitute a 0 when the input value is bad.
Finally configure an alarm expression to fire an alarm if the general property becomes zero.
Note: I don't generally recommend to have property translations to write to general property aspects as that may lead to excessive aspect directory transactions. But in this case, the state seldomly changes and the amount of transactions caused by this should be very low.