Solutions for real-time systems from SCADA to manufacturing

RTA allows the configuration of a HOT-STANDBY server that automatically takes over the functions of the MASTER server (by becoming itself MASTER) in case of problems (failover function). Applications on the STANDBY server can be programmed to be either be dormant (wait until failover before starting execution) or to do specific STANDBY processing. The STANDBY processing allows processing power of the STANDBY server being used for non-critical functions as long as both servers are up and running. They are of course not available if only one server is active because the active server automatically becomes the MASTER.

Both servers maintain their separate ORACLE database and store all process data in that database. The STANDBY server is, like the CLIENTS, synchronized from the MASTER server during normal operations.

The failover happens usually in less than a second after problems with the MASTER server have been identified. All these functions are made possible via the Real Time Redundancy Manager (RtRM).

RtRM, who also controls the local RTA tasks of all nodes in the RTA network, can detect faulty tasks (e.g. tasks that loop) and initiate the failover. Failover is transparent for the CLIENTS. They maintain normal operation, the only difference is that they now communicate with the other server - the NEW MASTER. This real-time switching is possible thanks to the RtRM and the fact that the RtRM supervises the RtIpC, telling it in real-time that messages have to be rerouted to the NEW SERVER.

Of course all these concepts that we have discussed so far require a reliable network connection. But what if we don't have that?

Is there a RTA solution for systems with unreliable networks?

STEP 5: The RTA MASTER - STANDBY Architecture