6. Redundancy with NX3030 CPU
297
ï‚· NX8000 power supply fault in the Active CPU
ï‚· Rack bus failure (NX9001, NX9002 or NX9003) in the Active CPU
ï‚· Failures in the NX3030 CPU from the Active CPU, such as:
o Watchdog
o Restart (reset warm, cold or origin)
o Stop
o Failure in the bus interfaces in one or both synchronization channels NETA and NETB
ï‚· Failures in the NX4010 from the Active PLC, such as:
o Not recognized module in the NX3030 CPU bus
o Failure in the NX4010 microprocessor which prevents the NETA/NETB and the PX2612
control panel (buttons, LEDs and relay) internal diagnostics updating
o Internal failures that affect one or both synchronization channels NETA and NETB
ï‚· Active PLC PROFIBUS network total failure, in case this network is configured in vital mode. In
case the PROFIBUS network is redundant, both composing networks must fail (double failure)
ï‚· Total failure of an Ethernet network in active CPU, if this network is configured with vital
failure. If the Ethernet network is redundant, both networks that compose it must be faulty
(double fault)
Failures Associated to Switchovers between Half-Clusters Managed by the User
Among the described transition in the Transition between Redundancy States section, some turn
possible the user to manage switchovers between half-clusters, due to failures that don’t generate
automatic switchovers.
There are very particularly cases which depend on the philosophy of each client. E.g.: a case where
the SCADA system loses the communication with the Active CPU, but keeps communicating with
the Stand-by CPU.
Some clients would rather to have a manual switchover, where the operator presses the PX2612
STAND-BY button, to the Active CPU. The switchover causes a communication retry with the new
Active CPU.
An alternative solution would be to cause a switchover by sending a command from the SCADA
system to the Stand-by CPU, which would transmit to the Active CPU through NETA/NETB, using
the RedCmdLocal (Stand-by CPU) and RedCmdRem (Active CPU) data structures to transport a
command equivalent to the PX2612 STAND-BY button.
It would be also possible the Active CPU detect its communication lost with the SCADA system
itself and to activate a command in the RedCmdLocal, equivalent to the PX2612 STAND-BY button.
This would be a totally automatic solution with no operator intervention that would be typically made
in the ActivePrg POU.
Through data structures described in the Diagnostics, Commands and User Data Structure section,
it’s possible to exchange diagnostics and commands between the half-clusters through NETA and
NETB. This way, the user can execute special redundancy managing for failures that normally
wouldn’t cause any switchover. Further details regarding these data structures are offered in the
following sections:
ï‚· Redundancy Diagnostics Structure
ï‚· Redundancy Commands
ï‚· User Information Exchanged between PLCA and PLCB
Below, is exemplified how the user can manage failures and execute a switchover due to an error in
the Ethernet interfaces from the Active PLC (this code should be used in the ActivePrg POU):
//Verify if NIC Teaming is enabled.
IF ((DG_NX3030.tDetailed.Ethernet.NET1.szIP = '0.0.0.0') OR
(DG_NX3030.tDetailed.Ethernet.NET2.szIP = '0.0.0.0')) THEN
//NIC Teaming enabled: error in two NETs to execute a switchover.