Redundancy
The OPC UA specification defines two types of server redundancy: transparent and non-transparent redundancy. With transparent redundancy, the transfer of functions from one server to another is transparent for the client, i.e. the client does not know that a failover process has occurred and therefore has no control over the failover behavior. In addition, the client does not need to take any action to continue sending or receiving data. With non-transparent redundancy, the failover process from one server to another and the actions to continue sending or receiving data are performed by the client. The client must know the redundancy configuration of the server and perform the necessary actions in order to benefit from the server redundancy in the event of a failover. The non-transparent redundancy defines various failover modes which, among other things, specify how many servers are actively involved in the communication or are available as purely passive systems in the event of a failover.
The TwinCAT OPC UA Server supports non-transparent redundancy with the operation modes "cold", "warm" and "hot". The differences in these three operation modes are explained below.
For non-transparent redundancy, OPC UA provides the data structures that allow the client to recognize which servers are available in the redundant server group, as well as server information that tells the client which failover modes the server supports. Based on this information, the client can determine what measures it needs to take to achieve failover. For this purpose, the ServerRedundancy object exists in the server's address space and indicates the redundancy mode supported by the server and the redundancy set, i.e., all servers that are part of the redundancy configuration.
Failover modes
The following table lists all supported failover modes for non-transparent redundancy.
Mode | Description |
|---|---|
Cold | Only one server can be active at a time in Cold Failover mode. This can mean that redundant servers are not available (not switched on) or are available but not running (the PC is running but the application is not started). |
Warm | In Warm Failover mode, the backup servers can be active but not make a connection to the actual data points (typically a system where the underlying devices are limited to a single connection). The underlying devices, such as the PLC, may have limited resources that only allow a single server connection. Therefore, only one server is able to retrieve data. |
Hot | In Hot Failover mode, all servers are switched on and ready for operation. In scenarios where servers retrieve data from a downstream device, such as a PLC, one or more servers are active and connected in parallel to the downstream device(s). These servers have only minimal knowledge of the other servers in their group and work independently. If a server fails or a serious problem occurs, its ServiceLevel drops (see below). After recovery, the server returns to the Redundant Server Set with an appropriate ServiceLevel to indicate that it is available. |
ServiceLevel
The ServiceLevel provides a client with information about the state of a server and its ability to deliver data. The ServiceLevel is a node of the byte data type with a value range from 0 to 255. The TwinCAT OPC UA Server currently sets the ServiceLevel statically to the value 255. The reason for this is that the server is able to retrieve data from more than one subordinate PLC controller. The ServiceLevel can therefore only display the state of the server application itself, but not that of the subordinate PLC controllers. The DeviceState object is available for the latter in the respective PLC address spaces.
Configuration
The server redundancy can be configured using the TwinCAT OPC UA Configurator. Two steps are necessary for this:
- Configuration of redundancy
- Adding the servers from the redundancy set as AdditionalServerEntry
Configuration of redundancy
When configuring server redundancy, you define which Failover mode the server provides and which other servers should be part of the redundancy configuration. These servers are identified via their ServerURI. The Failover mode and a list of ServerURIs are then stored by the server in its ServerRedundancy object (see above).
These settings can be configured via the TwinCAT OPC UA Configurator in the "Server Settings" tab, for example:
As the ServerURI itself does not yet contain any connection information (e.g. the server or discovery URL), this information must be made available to the client elsewhere. This is done via the so-called AdditionalServerEntry configuration. This allows a client to retrieve all necessary information from the server with a FindServers call and identify the connection information for a specific ServerURI. This configuration step is explained below.
Adding the servers from the redundancy set as AdditionalServerEntry
With the AdditionalServerEntry configuration, information from other TwinCAT OPC UA Servers is added to the FindServers call of a server. This allows a client to locate all servers from the redundancy configuration and connect to them. The following screenshot shows an exemplary FindServers call on the local TwinCAT OPC UA Server. The call returns three TwinCAT OPC UA Servers, which are also part of a redundancy configuration.
The client uses the ServerURI from the redundancy configuration to identify a server.
The AdditionalServerEntries can be configured via the TwinCAT OPC UA Configurator in the Server Settings tab, e.g:
When adding a new entry, certain fields are already filled in with a template. Please adjust these entries according to your configuration.
The specific values for ProductUri, ApplicationName, ApplicationUri and ApplicationType can be found in the OnlinePanel of the TwinCAT OPC UA Configurator:
The DiscoveryURL corresponds to the ServerURL that you usually use to connect to the respective server.