Redundancy

Operating mode

To define for each elementary variable which station takes charge of the processing in normal and rescue mode would be cumbersome. Thanks to its original database structure using data blocks (worksheets), TOPKAPI Vision enables to declare at this intermediate level which are the main and rescue stations; parameterizing work is this way simplified, and not significantly increased as compared to a stand alone application, while maintaining a flexible structure.

Nevertheless, it is possible to address any variable from any data block of the application.

For instance:

Station S1 acquires and processes data from PLC A1 as main station for this PLC. Station S2 is the auxiliary station for PLC A1.

Station S3 acquires and processes data for PLC A2.

Data block of PLC A2 (Station S3) use a reference to the word W23 of PLC A1. Station S3 asks the value of this word to station S1 or S2 depending on which is active at the time and processes the data.

The global declaration at the equipment level simplifies greatly parameterizing without losing any flexibility and efficiency of the system, as data acquisition on field bus is necessarily performed by station S1 or S2.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Functions AND services

Configuration

At the configuration stage, the declaration of main and secondary station for each equipment as described above being made, there is nothing specific to do: configuration is identical to a stand alone application. When application is saved, user is prompted to save locally (intermediate backup) or transmit to all stations to take into account configuration changes immediately.

In the last case, all stations on the network TOPKAPI VISION will be rebooted; reboots are not made simultaneously in order to always keep a station running and avoid loosing data.

Operation

In normal operating mode, the data processing is only taken in charge by the main station. Data are UNIQUE and not managed simultaneously by two stations in order to keep data consistency. Auxiliary station may be used as the control operator's interface, and will then behave as client of the main station.

The main station informs permanently the auxiliary station of changes in PLCs variables, internal values, fault acknowledgements, log information, etc., so that the auxiliary station can permanently start rescuing the main station using current values and context.

Other stations on the network behave as clients for the data processed by main/secondary station; they automatically direct their requests to the active station, without any user action being required.
 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Architecture conception

The system allows redundancy of supervision stations as well as data acquisition networks and PLCs.

The system architecture must be designed according to the security level expected, and to effects induced by the failure of each component.

Supervision redundancy

Failure of the supervision leads to the system total blackout. The first step should therefore be to make supervision redundant especially as this operation is easily manageable in terms of implementation.

In the example on the right, one must take into account the possibility of using different stations for supervising PLCs on the same network depending of the protocol used. As a matter of fact, the secondary stations polls the PLCs at a low frequency to notify possible communication breakdown.

PLCs network redundancy

In the above example, you may have one or several PLCs networks. If you have several, then a network failure will not affect the whole of the application; on the opposite, if you have only one network, a failure will result in a total blackout. It may be then prudent to install a redundant network as shown on the right.

Redundant PLCs

In the above example, failure of a PLC will result in a blackout of only data processed by this PLC. If this is not enough, then redundant PLCs should be installed as shown on the right.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

RTUs and time-stamped data particularities

When equipment are not connected permanently to the supervisory station, switching between main and secondary station does not operate exactly as above.

INCOMING CALLS TO RTUs

When a RTU calls successfully the main station, this station processes data.

If the call fails, it may be retried and lead to a connection to the secondary station, but that does not mean the main station is out of service (line busy or any other reason). The secondary station redirects the received data to main station which will process data; if main station is not available the secondary station will process the data.

The remote units shall be configured to guarantee the possibility of calls on one or several modems to main station, call retries, and the like for the secondary station.

OUTGOING CALLS TO RTUs

The main and secondary station have a permanent dialog in order to check if they are both 'alive'. If the secondary and main station cannot communicate, then the secondary station will consider it has to process the received orders.

If main station cannot establish communication with a remote unit despite several attempts, the secondary station is automatically elected as active station for this unit (which is the equivalent of a communication failure with a local unit), ant it will process the connection orders and the received data.