OPC Redundant Manager (Exaquantum/ORM)

Benefits

• Increases the reliability of Exaquantum to collect process data
• Caters for network and hardware failures
• Supports five or more redundant Exaopc servers
• Supports redundant non-Exaopc servers

Key Features

• Supports a ‘Warm’ switchover between OPC DA and HDA redundant pairs
• Asynchronous read of OPC DA data
• Synchronous writing of OPC DA data
• Reading OPC DA item properties from supported OPC servers
• Synchronous reading OPC HDA data from supported OPC servers

Introduction

ORM allows configuration of redundant OPC server pairs. Within each pair, one OPC server will be designated as the ‘Master’ OPC server with the other OPC server in ‘Standby’ mode. The Master OPC server will pass process data to the Exaquantum server. The Standby OPC server is connected to the Exaquantum server with the tags registered but with inactive groups.

When the current Master OPC server becomes unavailable, ORM will switch to the Standby server to activate the groups and become the new Master server.

Capabilities

OPC DA data is read asynchronously from the OPC server via the standard OPC Group connection point notification mechanism.

If the Exaquantum connection to both the Master and Standby OPC servers is lost then when the connection is re-established, ORM will attempt to use the previously designated Master OPC server.

After switchover, the Standby OPC server becomes the new Master OPC server and data is supplied from this server until communication is lost as defined in the following table:

	Master OPC Server Available	Master OPC Server Fails
Standby Available	Master remains the Master	Standby becomes the new Master
Standby Not Available	Master remains the Master	OPC Down Time is recorded for later possible OPC Data Recovery and the designated Master OPC server is not changed

If the current Master OPC server is shut down cleanly and sends an OPC shutdown notification to ORM then the switchover happens with minimal delay. If the current Master OPC server becomes unavailable unexpectedly, for example due to network failure, then the unavailability is detected by the ORM OPC server connection monitoring facility.

ORM can support a maximum of 16 OPC connections (OPC pairs) but this number could potentially be increased depending on the Exaquantum server loading due to the amount of process data being received.

Monitoring Server Connections

At a configurable poll period ORM checks the status of each OPC server. If the call to the Master OPC server fails, or if the Master OPC server status is ‘not running’ then switchover to the Standby OPC server is attempted. If that is also unavailable then an OPC down time is recorded by ORM and the Master OPC server designation is not changed. ORM continues trying to re-establish the connection to the OPC server(s) each poll period. When the connection is re-established, ORM uses the previous Master OPC server where possible as this is the server most likely to have available OPC HDA data.

OPC HDA Data Collection

ORM reads OPC HDA data in the following cases:

• History catch-up when Exaquantum starts up
• OPC Data Recovery

ORM reads data from the Master OPC Server, if it is available. If the Master server becomes unavailable while history catch-up or OPC Data Recovery is running, ORM attempts switchover to the Standby OPC server, which if successful, becomes the new Master for subsequent catch-up blocks.

For Exaopc OPC Server types (Exaopc-STN, Exaopc-XL and Exaopc-µXL), OPC HDA data is requested for the specific update rate of the item.

Please note that ORM does not include an OPC HDA Equalization Module as provided by Exaopc-RD to ensure that both OPC servers in a redundant pair have the same OPC HDA data available. This is a function of Exaopc-RD and not Exaquantum. For Exaopc, the Standby OPC server will not be storing HDA as its groups are not active.

OPC DA Data Write

ORM supports synchronous OPC DA data write. The data write is performed only to the current Master OPC server. If the Write fails because the current Master OPC server has become unavailable, but not yet detected by the ORM periodic connection check, then the switchover is attempted immediately and, if successful, the write attempted to the new Master OPC server.

OPC Property Access

ORM supports OPC DA property access where the property data is read as follows:

• When new OPC tags are configured in Exaquantum
• When an update of all property data is requested for a specific OPC Gateway via the standard Exaquantum administration tools
• When a scheduled update of property data for all OPC Gateways is performed

Property data is read on an asynchronous thread from the current Master OPC server and passed to the Exaquantum OPC. If the read of property data fails because the current Master OPC server has become unavailable but not yet detected by the periodic connection check then the request is retried on the Standby OPC server.

Exaquantum Features Supported Without Redundancy

The following Exaquantum features are supported by ORM subject to the OPC Gateway configuration and whether the underlying OPC Servers support them:

• OPC Equalization
• HIS Tag Generation
• OPC Logon Connection Test