Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA Enterprise SCADA

TABLE OF CONTENTS

Computer states in arbitration

Save PDF
Save selected topicSave selected topic and subtopicsSave all topics
Share
Share to emailCopy topic URL
  • Last UpdatedApr 24, 2025
  • 3 minute read

The various computer states that occur in the Arbitration process are described in the table below.

After the arbMonitor executes the appropriate startup script, it waits in the INIT state for the Database Synchronization state to be set to SYNCHRONIZED. If the arbMonitor executes a WARM STARTUP, then the database replication software is responsible for setting the Database Synchronization state. If a COLD STARTUP is executed, then the database is loaded from a persistence store and Database Synchronization will have been set by the arbMonitor. Once the Database Synchronization state is set to SYNCHRONIZED, the arbMonitor will move the state to STANDBY.

Computer State

Definition

Fail Pending

The dnaService process starts the arbMonitor process for the Arbitrated AVEVA Enterprise SCADA services. The arbMonitor process then creates the Arbitration Cache, sets the Arbitration State to PENDING and then starts the arbRx and arbTx processes.

Pending Init

The arbMonitor process stays in PENDING waiting to identify what the state of the partner host is. When arbRx has received this information, or a configured timeout has been reached, the state is moved to INIT.

Init Standby

Once in the INIT state, the arbMonitor process has enough information to determine what type of startup to execute.

Cold Startup

The partner is not Hot. In this case, arbMonitor sets the Database Synchronization state for the local host to SYNCHRONIZED. It then executes the cold_start.csc script found within %DnaInstallRoot%\<silo>\scripts\<serviceName>. The cold_start.csc script is expected to load the database from a persistent store or filesystem. It then starts all service processes.

Warm Startup

The partner is Hot. In this case, the arbMonitor sets the Database Synchronization state for the local host to STALE. It then executes the warm_start.csc script found within the %DnaInstallRoot%\<silo>\scripts\<serviceName> directory. The warm_start.csc script is expected to initialize the database, and then start the appropriate replication software and all associated service processes. The replication software is expected to set the Database Synchronization state within the Arbitration Cache to SYNCHRONIZED as soon as an integrity update of the Hot server’s database has been retrieved.

Standby Hot

If the arbMonitor process finds that neither computer is Hot, then it begins the actions to move the service state to Hot. This adheres to the following sequence:

  • While still in the Standby state, the arbMonitor executes the pre_assert.csc script within the %DnaInstallRoot%\<silo>\scripts\<serviceName> directory.

  • The arbMonitor sets the state of the service to Hot.

  • The arbMonitor executes the assert.csc script within the %DnaInstallRoot%\<silo>\scripts\<serviceName> directory.

Hot Standby (Hot, Do Switch, Switch, Standby)

If a failover is requested, the request moves the service state to Do Switch. The arbMonitor then begins the actions to move the service state to Standby. This adheres to the following sequence:

  • In the Do Switch state, the arbMonitor executes the stand_down.csc script found within %DnaInstallRoot%\<silo>\scripts\<serviceName>.

  • The arbMonitor moves the state to Switch.

  • In the Switch state, the arbMonitor waits until the other host has moved its state to Hot. It waits in this state for a configured timeout. If the other host does not go Hot within the timeout, then this service reasserts Hot. This involves the same execution sequence as the Standby to Hot state transition.

  • Finally, once the other host moves to Hot, the arbMonitor sets the state of the service to Standby.

Related Links