Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA™ Communication Drivers

Runtime Behavior

  • Last UpdatedOct 23, 2017
  • 2 minute read

The DAServer will start with the active device. The DAS Engine will switch to the standby device when the active device fails to communicate. The value of the $SYS$Status will determine the communication failure.

Note: The value of the $SYS$Status of the standby device must be TRUE in order to switch over to the standby device. Otherwise, there will not be any failover.

When $SYS$Status shows a FALSE value at both active and standby devices, the DAS Engine will consider a complete communication failure and mark all the items subscribed to the redundancy device hierarchy with the current time and the appropriate OPC quality. The DAS Engine will activate the slow-poll mechanism to retry the communication to both devices until either one of the Ping Items returns to a good quality and update its $SYS$Status item to TRUE.

When the DAS Engine switches to the standby device, the standby device becomes active and the originally active device becomes the standby.

When the active device becomes the standby device the Ping Item will not be deleted from that the standby device. This will ensure the standby will be able to recover the communication again.

Note: The Ping Item must be a valid item from the controller that has not been rejected by the server for the failover to function properly.

The DAServer will log any failover activities. All other functionality such as diagnostics, enable/disable, and reset will be performed exactly same as it is performed for any other hierarchy node.

Note: Unsolicited message configuration is not supported in the Redundant Device Object itself. You can still receive unsolicited messages directly from device groups defined in the regular server hierarchy.

This feature allows the DAServer to provide fail over support by providing one node which switches between two other nodes. The Redundant device is configured with a redundancy node which directs itself to one of the two nodes and switches to the other based on lack of communications to a common user-configured controller item. In this manner the Redundant Device Object can be used to direct client requests to the redundant node, which switches between device or communication pathway failure without intervention.

TitleResults for “How to create a CRG?”Also Available in