Two Types of Redundancy

The BMENUA0100 module supports the following types of redundancy:

  • Hot Standby architecture, which describes redundant CPUs.

  • OPC UA server redundancy, which describes the use of redundant BMENUA0100 modules.

The redundancy of OPC UA servers, which is managed by the BMENUA0100 modules, follows the OPC UA standard non-transparent server redundancy in warm failover mode.

These two types of redundancy can be combined. The following designs are supported:

  • A standalone PAC, containing two BMENUA0100 modules.

  • Two Hot Standby PACs, each containing one or two BMENUA0100 modules.

OPC UA Redundancy

In an OPC UA non-transparent server redundant architecture in warm failover mode, it is the responsibility of the OPC UA client to establish sessions and to manage communications with redundant servers. The sessions to be established include: an active session with the primary server and an inactive session with the secondary (or standby) server. The client needs to configure these two sessions to include the same monitored items.

It is also the responsibility of the OPC UA client to check the status of the two servers via the SERVICE_LEVEL variable, and to switch the communication to the healthier server, depending on the value of this variable.

The OPC UA standard holds that the activation of communications is accomplished by adjusting the Monitoring Mode of the different sessions to the right value. The Monitoring Mode of the servers is controlled by the OPC UA client, and the procedure for adjusting it depends on the implementation of the client. For more information about adjusting Monitoring Mode, refer to the client documentation.

This principle is a general principle, and applies to any architecture, including an the Hot Standby architecture.

The following diagram depicts an OPC UA client connected to a pair of redundant OPC UA servers (each embedded in a BMENUA0100 module). The client has designated as the active server the one with the higher SERVICE_LEVEL value:

Hot Standby

In a Hot Standby configuration, a maximum of two (2) BMENUA0100 modules can be installed in each Hot Standby main local rack. Each BMENUA0100 module is configured with a unique, static IP address. The BMENUA0100 modules will retain their respective IP addresses, and will not exchange IP addresses on a Hot Standby switchover or swap.

NOTE: In a Hot Standby system, verify that the BMENUA0100 modules in the primary and the standby PACs:

The system will not automatically perform these checks for you.

The BMENUA0100 module DDT includes the SERVICE_LEVEL variable, which provides information to the CPU regarding the health of the OPC UA server in the BMENUA0100 module. The OPC UA client is informed of the status of the OPC UA server via the SERVICE_LEVEL variable, which is available as an OPC UA variable.

NOTE: Always include the READ_DDT elementary function, for the purpose of updating the DDT of each BMENUA0100 module. In a Hot Standby configuration, add the READ_DDT to a code section that executes when the CPU is in standby mode. This design returns BMENUA0100 diagnostic information that can be exchanged between the primary and standby CPUs. The application can use this information to perform a consistency check of the supported services and the cybersecurity configurations for the BMENUA0100 modules in the primary and standby CPUs.

If the Hot Standby CPU T_M_ECPU_HSBY DDT and its CMD_SWAP element are made available as HMI variables in a SCADA system, the SCADA application can trigger a swap by writing to the appropriate mapped OPC UA variable in the BMENUA0100.

In a Hot Standby system, the BMENUA0100 module that manages OPC UA communications with the SCADA may be the one located in the standby local rack. For this reason, you need to select the Exchange on STBY attribute for all scanned application variables to provide consistency of variable values between the primary and standby PACs.

In addition, to maintain consistency, the applications in the two Hot Standby PACs need to be synchronized.

In rare cases (primarily when the ECPU_HSBY_1.PLCX_ONLINE bit is set to false either manually or programmatically), one of the PACs in a Hot Standby system may be in Wait mode. In this mode, this PAC (the standby) is not synchronized with the primary PAC and variables read from this PAC are inaccurate. The state of a responding PAC may be monitored via the following T_M_ECPU_HSBY DDT fields:

  • T_M_ECPU_HSBY_1.LOCAL_HSBY_STS.WAIT

  • T_M_ECPU_HSBY_1.LOCAL_HSBY_STS.RUN_PRIMARY

  • T_M_ECPU_HSBY_1.LOCAL_HSBY_STS.RUN_STANDBY

  • T_M_ECPU_HSBY_1.LOCAL_HSBY_STS.STOP

Also, the Hot Standby system permits the two PACs to operate while running different applications. To provide for the consistency of variables between the primary and standby PACs, the data layout of the 2 PACs needs to be consistent, as shown by the T_M_ECPU_HSBY DDT field:

  • T_M_ECPU_HSBY_1.DATA_LAYOUT_MISMATCH = false

NOTE: When OPC UA redundancy is configured, it is recommended that you programmatically check the module DDTs to confirm that the supported services and the cybersecurity configurations for the BMENUA0100 modules are consistent.
NOTE: In the following parts of this topic, content is borrowed from the document:

OPC Unified Architecture Specification Part 4: Services, Release 1.04, which is abbreviated below as OPC UA Part 4, followed by the appropriate section reference. The borrowed content appears in italics.

OPC UA Support for Redundant Servers, Clients, and Networks

OPC UA enables Servers, Clients and networks to be redundant. OPC UA provides the data structures and Services by which Redundancy may be achieved in a standardized manner.

Server Redundancy allows Clients to have multiple sources from which to obtain the same data. Server Redundancy can be achieved in multiple manners, some of which require Client interaction, others that require no interaction from a Client. Redundant Servers could exist in systems without redundant networks or Clients. Redundant Servers could also coexist in systems with network and Client Redundancy...

Client Redundancy allows identically configured Clients to behave as if they were single Clients, but not all Clients are obtaining data at a given time. Ideally there should be no loss of information when a Client Failover occurs. Redundant Clients could exist in systems without redundant networks or Servers. Redundant Clients could also coexist in systems with network and Server Redundancy...

Network Redundancy allows a Client and Server to have multiple communication paths to obtain the same data. Redundant networks could exist in systems without redundant Servers or Clients. Redundant networks could also coexist in systems with Client and Server Redundancy... OPC UA Part 4, section 6.6.1.

Server Redundancy

There are two general modes of Server Redundancy, transparent and non-transparent.

In transparent Redundancy the Failover of Server responsibilities from one Server to another is transparent to the Client. The Client is unaware that a Failover has occurred and the Client has no control over the Failover behaviour. Furthermore, the Client does not need to perform any actions to continue to send or receive data.

In non-transparent Redundancy the Failover from one Server to another and actions to continue to send or receive data are performed by the Client. The Client must be aware of the Redundant Server Set and must perform the required actions to benefit from the Server Redundancy.

The ServerRedundancy Object ... indicates the mode supported by the Server. The ServerRedundancyType ObjectType and its subtypes TransparentRedundancyType and NonTransparentRedundancyType ... specify information for the supported Redundancy mode. OPC UA Part 4, section 6.6.2

As noted above, the OPC UA server in the BMENUA0100 supports non-transparent server redundancy in warm failover mode.

OPC UA Server Warm Failover Mode

Warm failover mode is where the backup Server(s) can be active, but cannot connect to actual data points. Therefore, only a single server will be able to consume data of the Control Expert application. The ServiceLevel Variable ... indicates the ability of the Server to provide its data to the Client. OPC UA Part 4, section 6.6.2.4.4

When there is failover, action by the OPC UA client is needed; the OPC UA server embedded in BMENUA0100 becomes inactive:

Client Failover Behavior

Each Server maintains a list of ServerUris for all redundant Servers in the Redundant Server Set.

NOTE: A Redundant Server Set is the collection of OPC UA servers in the Control Expert application that are configured to provide redundancy.

The list is provided together with the Failover mode in the ServerRedundancy Object. To enable Clients to connect to all Servers in the list, each Server in the list shall provide the ApplicationDescription for all Servers in the Redundant Server Set through the FindServers Service. This information is needed by the Client to translate the ServerUri into information needed to connect to the other Servers in the Redundant Server Set. Therefore, a Client needs to connect to only one of the redundant Servers to find the other Servers based on the provided information. A Client should persist information about other Servers in the Redundant Server Set. OPC UA Part 4, section 6.6.2.4.5.1

Client options in warm failover mode include:

  • On initial connection, in addition to actions on Active Server:

    • Connect to more than one OPC UA Server.

    • Create Subscriptions and add monitored items.

  • At failover:

    • Activate sampling on the subscriptions.

    • Activate publishing.

Clients communicating with a non-transparent Redundant Server Set of Servers require some additional logic to be able to handle Server failures and to Failover to another Server in the Redundant Server Set. The following figure provides an overview of the steps a Client typically performs when it is first connecting to a Redundant Server Set.

The initial Server may be obtained via standard discovery or from a persisted list of Servers in the Redundant Server Set. But in any case the Client needs to check which Server in the Server set it should connect to. Individual actions will depend on the Server Failover mode the Server provides and the Failover mode the Client will make use.

Clients once connected to a redundant Server have to be aware of the modes of Failover supported by a Server since this support affects the available options related to Client behaviour. A Client may always treat a Server using a lesser Failover mode, i.e. for a Server that provide Hot Redundancy, a Client might connect and choose to treat it as if the Server was running in Warm Redundancy or Cold Redundancy. This choice is up to the client. In the case of Failover mode HotAndMirrored, the Client shall not use Failover mode Hot or Warm as it would generate unnecessary load on the Servers. OPC UA Part 4, section 6.6.2.4.5.1

OPC UA Client Warm Failover Mode

In Warm Failover mode, the Client should connect to one or more Servers in the Redundant Server Set primarily to monitor the ServiceLevel. A Client can connect and create Subscriptions and MonitoredItems on more than one Server, but sampling and publishing can only be active on one Server. However, the active Server will return actual data, whereas the other Servers in the Redundant Server Set will return an appropriate error for the MonitoredItems in the Publish response such as Bad_NoCommunication. The one Active Server can be found by reading the ServiceLevel Variable from all Servers.

The Server with the highest ServiceLevel is the Active Server. For Failover the Client activates sampling and publishing on the Server with the highest ServiceLevel. Figure 30 illustrates the steps a Client would perform when communicating with a Server using Warm Failover mode.

OPC UA Part 4, section 6.6.2.4.5.3