High availability with Topkapi
High availability is an essential issue for IT applications. Thus, the unavailability of scada applications can have a negative impact on your operational efficiency and associated costs.
Ensuring continuity of service with the Topkapi software
When a supervisory position fails, the operator has no visibility of the facilities and is temporarily unable to operate and monitor them. The data are no longer recorded in the history, thus causing a loss of data traceability.
The redundant operation of the Topkapi servers meets the need for high availability and allows - when a workstation is faulty or when communication with a piece of equipment is interrupted - to automatically switch the corresponding processing to a second workstation without operator intervention. When the faulty element becomes active again, a dialogue between the main station and the emergency station automatically restores normal operation and makes the data from the two stations consistent.
Moreover, Topkapi's multi-station processing, which comes with the redundancy option, makes it possible to design a single application that is processed on several networked stations and to assign different processes to each station. This distribution improves performance by sharing processing times and limits the risks in the event of failure of one of the workstations.
More information about the redundancy module
Operation
Thanks to its original database structure, the Topkapi software platformSCADA software 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.
Special feature of remote management and redundancy
When equipment are not connected permanently to the supervisory station, switching between main and secondary station does not operate exactly as above.
1. 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.
2. 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.
Possible detailed architectures
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 below, 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.
PLC 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 below.
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 below.
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 below, 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.
PLC 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 below.
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 below.
