6. Redundancy with NX3030 CPU
299
situations, such as process programmed maintenance, are used for that purpose. The higher the
period between off-line testes, the higher the time which the failure may remain hidden, and the
higher the probability of a failure to damage the system, in other words, the smaller the
availability
These principles were considered in the redundant CPU project using NX3030.
The next sub-sections analyze several failure types and how they are tolerated or not, and if there are
switchovers associated to the tolerated failures.
Simple Failure with Unavailability
Some components, as they aren’t doubled, don’t even tolerate a simple failure without causing some
kind of unavailability. In a redundant CPU using CPU NX3030, this is related to the following
components:
ï‚· PROFIBUS remotes (slaves) in a non-redundant PROFIBUS network
ï‚· Ethernet remotes (slaves) in a non-redundant network
ï‚· I/O Modules
The failure intolerance of a non-redundant PROFIBUS network can be solved if a redundant
PROFIBUS network is used, which is advisable in systems that demand a high failure tolerance.
Figure 6-1 shows an example of a redundant PROFIBUS network architecture. Likewise intolerance
to failure of a non-redundant Ethernet network can be solved by using a redundant Ethernet network
configuration with NIC Teaming.
Regarding the I/O module unavailability, it must be observed that it doesn’t imply total system
unavailability. It constitutes a partial unavailability, only in the control mesh that uses this I/O
module.
Even though there’s no redundancy prevision for I/O modules, the user application can manage it in
special cases. E.g. the user can insert 3 analog input modules in 3 different PROFIBUS remotes, and
implement a vote scheme between analog inputs triples, for a critic system. However, as mentioned,
such solutions must be managed by the user. There’s no automatic support for them. Such solutions,
generally speaking, also imply in the field transducers and actuators redundancy.
Simple Failure without Unavailability Causing a Switchover
Some redundant components tolerate simple failures without causing unavailability, but do cause
switchover:
ï‚· Racks (NX9000, NX9001, NX9002 or NX9003).
ï‚· Power Supply (NX8000).
ï‚· CPUs (NX3030)
ï‚· NX4010 modules
ï‚· NX5001 modules (PROFIBUS masters) in non-redundant PROFIBUS network configuration
ï‚· NX5000 module (Ethernet) in configurations without NIC Teaming
ï‚· PROFIBUS slave interface in a redundant remote (PO5063V5, PO5065, NX5210 or AL-3416).
In this case, different from the previous, the switchover happens inside the remote, between the
PROFIBUS A and B networks
ATTENTION:
In case of failure of the CPU NX3030 or NX4010 module in architectures where panel PX2612 or
PROFIBUS network is not used, the CPU will remain in its current state. In this case, if the failure
occurs in the half-cluster active, system downtime occurs.
Double Failure without Unavailability Causing a Switchover
Some components are doubled in each half-cluster, this way, before causing a switchover, both must
fail: