User manual

Toolbox 32 User Manual 1.47d www.cse-semaphore.com/mykingfisher
Page
209
Redundant RTUs
It is useful to have a primary and a secondary RTU for a number of reasons:
• All the telemetry system data can be viewed from either RTU
• If the primary RTU fails, the secondary RTU can take control of the system (optional)
• Using completely separate RTUs maximises electrical and physical isolation
Primary RTU1
Secondary RTU2
Radio Repeater
Remote RTUs
A primary master RTU and a secondary master RTU are configured like any other RTUs with unique
addresses. The primary RTU polls the outstations and acknowledges exception reports while the secondary
RTU simply listens to all the messages from the outstations and updates its own network data. This prevents
both master RTUs acknowledging the same message.
Both RTUs need to know the address of the other master RTU (configured in ladder using #Y2NDRTU).
Each master RTU is then configured to be in either listen or control mode (configured in ladder using
#Y2NDSTAT). When in listen mode, the secondary master RTU updates its network data when it hears new
data from an outstation RTU but does not acknowledge or initiate messages. When in control mode, the
secondary master RTU acts the same way as the primary master RTU.
There are various ways to configure primary and secondary RTUs with varying complexity. Two different
ways are shown below.
Transferring Data Between Two RTUs
To transfer all the data from one RTU to another (including event logs) over a dedicated comms link (eg.
modem or Ethernet), the first RTU can use a TX Images block to transfer all its network data, and a TX
Update Event Logs block to transfer all its event logs if required. A primary / secondary setup is not required
in this instance. The main disadvantage with this arrangement is that data will not be received
simultaneously by both RTUs as the second RTU is not able to overhear messages to the first RTU and
must wait for the new data to be relayed on. However, data can be updated in the second RTU relatively fast
if the first RTU monitors when its network data has changed (using #YLUPDC ) and then initiates a TX
Images message to the second RTU. New event logs can also be relayed quickly by monitoring when the
event log pointer changes ( #YLOGIDX ) and then initiating a TX Update Event Logs message.
Secondary RTU Always Listens
For this example, the Primary RTU has polling ladder logic while the secondary RTU behaves like an
outstation RTU and does not have polling ladder logic.
The example below shows the primary RTU always in control mode and the secondary RTU always in listen
mode. This method prevents any clashing of the master RTUs caused when both RTUs think they are in
control but does not allow the secondary RTU to take control if the primary RTU fails. If the secondary RTU
does not hear from the primary RTU for 35 minutes (waits for a bit longer than 2 polls), the secondary RTU
flags a primary RTU comms fail but does not take control. The example includes polling for 2 outstation
RTUs and includes a periodic check of the secondary RTU (using the TX IMAGES block) to ensure it has the
latest data. The TX IMAGES block checks that the secondary RTU has the same data for RTUs 3 and 4.