6. REDUNDANCY WITH NX3030 CPU
Program periodic offline tests in components in order to detect not automatically diagnosable failures by the system.
The objective is to detect hidden failures, especially in redundant components or simple components which aren’t being
requested (e.g. a security relay). Offline tests, sometimes, imply in system stopping what decreases the availability.
Normally, special situations, such as process programmed maintenance, are used for that purpose. The higher the period
between offline tests, 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.
6.3.21.1. 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 164 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.
6.3.21.2. Simple Failure without Unavailability Causing a Switchover
Some redundant components tolerate simple failures without causing unavailability, but 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 modules (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.
6.3.21.3. Double Failure without Unavailability Causing a Switchover
Some components are doubled in each half-cluster, this way, before causing a switchover, both must fail:
NX5001 modules (PROFIBUS masters) in redundant configuration, configured in vital failure mode.
NX5000 modules (Ethernet) in configurations with NIC Teaming (redundancy managed by the user).
302
To Next Page
Loading...
Need help?
General
