Establishing Redundancy

Database Exchange

The Quantum Hot Standby provides redundancy by maintaining its Standby PLC and associated modules in a state where they can assume the Run Primary operating mode quickly. This means that the Standby PLC must have all of the information necessary to mirror the I/O and data states present on the Primary PLC and that this information must be regularly updated. For the Ouantum Hot Standby, the collected information is called the "database" and the regular exchange of this database is referred to as the "database transfer".

Just after the Primary PLC finishes reading the input values it transfers the database to its Copro, which in turn transmits it over the CPU-sync link to the Standby PLC Copro. The Standby PLC then applies the information in the database as required.

The database that is cyclically transferred from the Primary PLC to the Standby PLC (via the Copros and the CPU-sync link) includes both system data and user application data and I/O. In both cases, some of this data is located (addressable) and some is unlocated. The data exchanged during every MAST task are listed below.

System Information

LOCATED:
- System Bits:
  
  %S30 - %S35: activation of tasks
  
  %S38: enabling/inhibition of events tasks
  
  %S50: clock write
  
  %S59: clock increase
  
  %S94: replace current value
  
  %S117: RIO Error on Ethernet I/O Network
  
  %S118: RIO Error on S908 I/O Network
- System Words:
  
  %SW0 - %SW5: Set scanning period for tasks
  
  %SW8 - %SW9: task Input/Output inhibition
  
  %SW49 - %SW53: date and time information
  
  %SW59: updates date and time values
  
  %SW60: Hot Standby Command register, refer to Hot Standby Command Register
  
  %SW70: current time date
  
  %SW98 - %SW99: CCOTF compatibility flags for CRA Drop modules
  
  %SW108: number of currently forced bits
  
  %SW109: number of forced analog channels
  
  %SW152 - %SW155: Ethernet RIO drop errors
  
  %SW172 - %SW175: Hot Standby drop errors
  
  %SW180 - %SW181: Local drop module health bits (main rack and extension rack)
  
  %SW182 - %SW183: Peer drop module health bits (main rack and extension rack)
  
  %SW185 - 339: S908 RIO Drop module health bits
  
  %SW641 - 764: Ethernet RIO Module Health bits
- Reverse System Words:
  
  %SW62 - 65: data transferred from the Quantum Hot Standby CPU to the Primary CPU
NOTE: For a detailed description of these System Bits and System Words, refer to EcoStruxure™ Control Expert, System Bits and Words, Reference Manual.

User Application Data

LOCATED:

All %M, %MW, %MD, %I and %Q data from address 1 up to the maximum number of global address fields configured in Control Expert's Configuration tab, but no more than 128 KB. A range of %MWs can be defined as a "non-transfer area", they are not transferred to Standby controller.
- The output (%Q) objects and any output forcing settings.
- EDT / DDT when they are located by the user.
- Sequential Function Chart (SFC) data types.
UNLOCATED:
- EDT / DDT when they are located by the system.
- Function Block (EFB / DFB) data types.

Maximum amounts of data that can be transferred in the database:

CPU	Located	Unlocated
140 CPU 671 60	128 kbytes	512 kbytes
140 CPU 671 60S		385 kbytes
140 CPU 672 60		1536 kbytes
140 CPU 672 61
140 CPU 678 61

For specific information about the command words and adjustment parameters and the maximum memory sizes of these areas, refer to the EcoStruxure™ Control Expert, Operating Modes.

For more information on the database transfer, including information about the application of this information by the Standby controller, refer to Quantum Hot Standby Data Transfer.

Synchronized Program Execution

By itself, the regular exchange of system and user application data is not enough to synchronize the Standby controller with the Primary controller. It is also important that the cyclical execution of tasks on each controller remains aligned, so that neither controller races ahead of the other controller that is still processing its information. This means that the Primary controller sometimes has to wait for the Standby to finish processing and that the Standby sometimes has to wait for information from the Primary.

This requirement for aligned program execution requires that the task execution cycle is deterministic. For this reason, only MAST tasks are used when programming a Quantum Hot Standby system. For more details about the requirement for MAST tasks and their execution in a Hot Standby context, see Exclusive Use of MAST Tasks and Adjusting MAST Task Properties.

Switchover Events

While this manual covers Switchover events in some detail, a few general statements aid understanding of these subsequent topics:

Much of the benefit of the Quantum Hot Standby system is its ability to detect various error conditions and, when necessary, initiate a Switchover. The type of error detected determines the duration of the Switchover event. For example:
- If the Primary PLC is online and can communicate with the Standby PLC, but detects an error that requires a Switchover, it commands the initiation of a Switchover event. In this instance, the Switchover duration is just that required for the Switchover event, which usually takes about 1.5 - 2 MAST tasks.
- If the Primary PLC is no longer operable, or all communications between the Primary and Standby controllers are lost, an automatic Switchover occurs. The duration of this type of Switchover equals 2 MAST cycles + any configured Watchdog for the MAST task.
Local I/O is not part of an automatic Switchover. Local I/O is managed locally (by the CPU in the rack where the local I/O resides)) and continues to operate after a Switchover under the control of its local CPU.

USB Link Switchover Behavior

During a switchover the USB link that is the communication between one of the PLCs and the Control Expert workstation does not switch over. The link remains with the same PLC, therefore, the link must be manually switched to the other CPU, if necessary.