6. HX3040 Redundancy
273
In other situations, the user must request this configuration manually, e.g. pressing a button over the
CPU’s display menu. Manual configuration requests usually are not necessary in maintenance
situations (before leaving the Non-Configured state). E.g. if the CPU has not reached the Non-
Configured state due to some failure.
After leaving the Non-Configured state, it is possible for the CPU to go back to it in events such as:
Restarting (Reset warm, cold or origin)
CPU switch off
Different projects between the current CPU and the Active CPU
Starting State
Unlike the other 4 states, which can last indefinitely, the Starting state is temporary and goes on for
few seconds. The CPU reaches the Starting state from the Non-Configured one, through a
configuration request.
At the beginning of the Starting state, several actions, tests and verifications are executed, in order to
decide which will be the next state:
The CPU accounts only for the local bus, with no interference in the modules control.
The CPU checks whether its identification is correct or not (CPUA or CPUB, according to where
the CPU is inserted).
The CPU checks if there are problems in the configuration parameters extracted from MasterTool
project.
The CPU executes cyclic synchronization services as long as the conditions for its execution are
true (see Cyclic Synchronization Services through Redundancy Synchronism Channels).
The CPU checks the compatibility of the firmware version between both CPUs.
The CPU checks if the projects from both CPUs are equal.
In case the other CPU is in Active mode, the current state analyses the possibility of establishing
a passive communication, through the local bus of the modules. The passive mode is used to test
the transmission and reception circuits and the physical layer, to avoid hidden flaws.
In case the other CPU is in unknown state due to failures in the redundant synchronism channels,
it analyses the possibility of establishing a passive communication through the local bus of
modules.
Depending on the results of these verifications and tests, the CPU switches from the Starting state to
any of the other ones.
Active State
In this state, the CPU controls the automated process, using the UserPrg program, which runs only in
this state. The Active CPU also updates the remote I/O modules, keeping them in an operational
mode and reading the inputs and writing the outputs.
The Active CPU also verifies its internal diagnostics and the user switchover requests to determine if
a switchover is necessary. The CPU leaves the Active state only if it is aware that the other CPU is in
Stand-by mode, ready to take the control.
However, there are some situations where the Active CPU can leave the Active state even with no
certainty about the other CPU’s state. That is the case when the CPU is removed of the rack, for
instance.
Stand-By State
In this state the CPU is ready to be switched to the Active state in case there is a request for that (a
failure in the current Active CPU, for example).
The Stand-by CPU also verifies its own diagnostics and can be switched to the Non-Configured or
Inactive state, in case some failures occur.
