Run-time behavior of redundant devices
- Last UpdatedJul 29, 2024
- 2 minute read
The Communication Driver starts with the active device. The OI Engine switches to the standby device when the active device fails to communicate. The value of the $SYS$Status determines 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 OI Engine considers 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 OI Engine activates 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 OI 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 ensures the standby is able to recover the communication again.
Note: To allow the failover to function properly, the Ping Item must be a valid PLC item that has not been rejected the server. System items (items beginning with $SYS$) cannot be used as the Ping Item. See SIDirect Communication Driver diagnostic info items for the list of system items.
The Communication Driver logs any failover activities. All other functionality such as diagnostics, enable/disable, and reset is 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 Communication Driver 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.
In both stand-alone and redundant configurations, the SIDirect Communication Driver supports subscription and poking. Block services are not supported.