Process of arbitration within an arbitrated service

Arbitration is comprised of a collection of processes, shared memory, and sockets working together to ensure redundancy.

The facilities pictured above are generic; however, there is an instance of each of these running within each arbitrated AVEVA Enterprise SCADA Service, started as processes that are members of the given service.

The roles of the above participants are described below.

Arbitration Cache (shared memory)

This is a shared memory segment that contains the state of the service. Each Arbitration Cache contains the following elements:

• Arbitration State for service on this host

• Database Synchronization State for this host.

• Arbitration State for service on partner host

• Database Synchronization State for the partner host.

• Greenwich Mean Time (GMT) of the last received message from the partner host (as received by arbRx) This segment is designed to be high speed, and is accessed through the Arbitration API that abstracts the underlying details of the cache.

arbMonitor Process

This is the first process to execute during the startup of an arbitrated AVEVA Enterprise SCADA service. arbMonitor is responsible for three primary tasks:

• Execute the startup sequence for arbitrated services.

• arbMonitor will timeout the host and set the partner service state to FAIL, if the last received service message from the other host is beyond a configurable timeout

• Ensure that one host is always Hot, and take any necessary actions related to this mandate. This process is used to determine which actions should be taken at any given moment.

arbRx Process

This process is responsible for receiving messages and updating the state of the service running on the other host.

arbTx Process

This process is responsible for opening a TCP/IP socket and transmitting messages containing the state of the service on the current host. These messages are sent on a configurable periodic interval, with a default of one message every 500 millisecond (ms).

Service Processes

Any process that is a member of the given service is expected to use the Arbitration Application Programming Interface (API) to determine whether the state of the service is Hot. If so, then such processes are expected to perform normal operational duties. If the state is not Hot, then such processes are expected to suspend normal operational duties.

In this way, processes can continue to run while the service is Standby. The processes do not need to be started when the service goes Hot.