6. HX3040 Redundancy
278
Common Failures which Cause Automatic Switchovers between CPUs
This section lists the most common faults, which automatically cause a switchover between CPUs
(Active to Non-active / Stand-by to Active). These failures trigger a subset of those transitions
examined on the previous section (Transition between Redundancy States).
Failure in the internal power circuit of the Active CPU
The Active CPU cannot access to the rack bus
Failures in the Active CPU, such as
o
Watchdog
o
Reboot (Reset Warm, Reset Cold or Reset Origin)
o
Failure of the bus interfaces on one or both synchronization channels (NETA and NETB)
Software Exception in the Active CPU (watchdog job, memory access error, etc.)
Failures Associated to Switchovers between CPUs Managed by the User
Among the situations examined in Transition between Redundancy States, some allow the user to
manage switchovers between CPUs, due to failures that usually do not generate automatically
switchovers.
There are rare cases that depend on the client’s philosophy. Take as example a situation in which the
SCADA system loses communication with the Active CPU.
Some customers would prefer a manual switchover, where the operator executes the command from
the menu on the CPU display. The switchover would retake the communication with the new Active
CPU.
Another possibility would be the Active CPU itself detect the loss of communication with the
SCADA, and activate a command in RedCmdLocal using the RedCmdLocal data structures to carry
an equivalent command to the one placed on the CPU display. This would be a fully automatic
solution that would dismiss any intervention by the operator, and it would typically be implemented
in UserPrg POU.
Through data structures such as those previously cited (Diagnostics, Commands and User Data
Structure), you can exchange diagnostics and commands between the CPUs via redundancy internal
link. Thus, the user can perform special managements of redundancy for failures that normally would
not cause switchovers. See further details on these data structures in:
Redundancy Diagnostics Structure
User Information Exchanged among CPUA and CPUB
The example below shows how the user can manage failures and perform a switchover in two cases.
The former regards a “link down” error in the Ethernet interfaces of the Active CPU (broken network
cable; use the code in the UserPrg POU). The later refers to the control of communication protocol
errors in the serial ports:
//The CPU checks if NIC Teaming is enabled or not.
IF ((DG_HX3040.tDetailed.Ethernet.NET[1].szIP = '0.0.0.0') OR
(DG_HX3040.tDetailed.Ethernet.NET[2].szIP = '0.0.0.0')) THEN
//NIC Teaming enabled: error in both NETs to perform a switchover.
IF (DG_HX3040.tDetailed.Ethernet.NET[1].bLinkDown AND
DG_HX3040.tDetailed.Ethernet.NET[2].bLinkDown) THEN
//Puts the Local CPU in StandBy.
DG_HX3040_01.RedCmdLoc.bStandbyLocal := TRUE;
END_IF
ELSE
//NIC Teaming disabled: error in one NET to perform a switchover.
IF (DG_HX3040.tDetailed.Ethernet.NET[1].bLinkDown OR
DG_HX3040.tDetailed.Ethernet.NET[2].bLinkDown) THEN
//Puts the Local CPU in StandBy.
