3. Design
3.4. Quantum Hot-Standby System
This chapter describes the different features and specifications of a redundant Quantum PAC system.
3.4.1. Quantum PAC Specifications
Primary and Standby PACs
Primary PAC runs the whole application program including the first section. It handles remote I/Os and updates the redundant PAC after each program cycle.
If the Primary PAC stops, the Standby PAC takes over the control from the Primary PAC in one cycle.
Standby PAC only runs the first section of the application program, checks the CPU and CRP modules availability and does not handle remote I/Os.
Note: CRP modules are needed in a Quantum Hot-Standby configuration, even if the system does not use remote I/Os. In this case, the two CRP modules are linked for monitoring purposes.
Local I/Os can be configured and used in a Hot-Standby Quantum system. However, they are not saved on the Standby system. They can be written in the Standby system with different values using the first section of the program (section 0).
Moreover, the output modules management can only be performed using variables that are not transferred from Primary to Standby PAC.
Hardware Constraints
•
Non-compatible modules:The following modules can not be used in a Quantum Hot-Standby configuration:
140N WM 100 00 140N OC 771 00
Note: Modules 140NOE77100 and 140NOE77110 are not available anymore.
•
Local I/Os:The term “local I/Os” refers to the I/O modules located in the local rack, which do not take part in the redundancy system.
When no programming has been specified, the Standby CPU outputs state is imposed by the Primary CPU. Standby CPU outputs can be programmed in the section 0 (which is the only section executed in the Standby CPU) and they take the specified status unless they are forced in the Primary CPU.
Standby CPU inputs status (%l readable in the application and from the animation table) does not reflect the hardware Standby CPU inputs status, but instead is related to the Primary CPU inputs status.
The Standby module byte status indicates:
- the Primary module status in the case of a mixed module
- the Standby module status in the case of an output module (DDO)
It is important to manage the locals I/Os in the section 0 only by using the %MW words of the non transfer area.
•
Remote I/Os:Communication modules cannot be used in a Remote I/O rack within a Hot-Standby application.
Software Constraints
We recommend not using TIMER events as they are not synchronized in Quantum Hot-Standby applications.
3.4.2. Quantum Hot-Standby DFBs Library
The following table summarizes the different DFBs created for the Quantum application.
DFB FUNCTION
ETHERNET NOE_MONITOR Monitoring NOE Ethernet Module PROFIBUS PTQ_MONITOR Monitoring PTQ Ethernet Module
SYNTH_FAULT Synthesis Fault monitored elements SYNTH_OR_NOE Synthesis Fault NOE module (Logic OR) SYNTH_AND_NOE Synthesis Fault NOE module (Logic AND) SYNTH_OR_PTQ Synthesis Fault PTQ module (Logic OR) SYNTH_AND_PTQ Synthesis Fault PTQ module (Logic AND) SWITCHOVER SWITCH_MANG Switchover Managment
SYNTHESIS
Ethernet link monitoring DFBs NOE_Monitor
The NOE_Monitor DFB monitors the Ethernet link hosted by the N module.
OE
llows The monitoring is managed by the MBP_MSTR block function integrated in the NOE_Monitor DFB. The MBP_MSTR block a performing operations on communication networks, for example, the extraction of the local statistics of the NOE module.
ENABLE ACTIVE
This extraction rate is controlled by the “Monitor Rate” parameter configured by the user. Extracted data is available on output pins as shown on the diagram on the left.
BOOL MSTR_ACTIVE MSTR_ACTIVE BOOL
BOOL MSTR_DONE MSTR_DONE BOOL
BOOL MSTR_ERROR MSTR_ERROR BOOL
INT RateEt RateEt INT
INT Error_Count Error_Count INT
ARRAY[0..9]OF INT MSTR_Control MSTR_Control MSTR_DataBuf
BYTE Slot Data_TCP DIAG_TCP
INT MonitoringRate LED_APPL BOOL
INT Retries LED_LINK BOOL
BOOL Pulse LED_RUN BOOL
NOE_Failure BOOL
NOE Local statistics
In order to diagnose the health status of the NOE module, we check the status of the module and the link thanks to respectively Led RUN and Led Link. The number of faults is given by the MPB_MSTR. This number is compared to the “retries” value, if the number of faults is greater or equal than the “retries” value the NOE_Failure is set to 1.
The block implementation is associated to a data structure NOE_Monit.
+ MSTR_Control ARRAY[1..9] OF INT + MSTR_DataBuf ARRAY[0..37] OF WORD
+ MSTR_Data Diag_TCP
During the implementation the block is used as many times as the number of NOE modules.
Profibus link monitoring DFBs PTQ_Monitor
Fault Timeout TIME Fault_Timeout PTQ_FAULT BOOL General PTQ fault
Master PTQ Status WORD Master_Status Faulty_Active BOOL Active PTQ fault Master PTQ Operating WORD Master_Operating_State
Active PTQ Status BYTE Active_Status Faulty_Passive BOOL Passive PTQ fault Nb slaves seen by active PTQ BYTE Active_NbSlave
Passive PTQ Status BYTE Passive_Status Faulty_Passive_UDP BOOL Passive PTQ fault via UDP Nb slaves seen by passive PTQ BYTE Passive_NbSlave
Passive PTQ Status via UDP BYTE PassiveP_Status_UDP Nb slaves seen by passive PTQ via UDP BYTE Passive_NbSlave_UDP
PTQ_Monitor
A Quantum Hot-Standby system does not handle automatically the PTQ-PDPMV1 module redundancy. However, this module provides enough information about the health status of the Active and Passive Master (Active = Primary and Passive = Standby) to be able to develop a DFB to manage redundancy.
The health status information circulates through the Profibus network. That means that, if the Profibus link is lost, the modules are not able to communicate their health status. Therefore, we use the Ethernet UDP capability (“PTQ Link Message”) to set up the PTQ module redundancy function. An Ethernet crossover cable is needed to link the two modules. Thus, the Primary module can access the health status of the Standby module even if the communication link is lost.
Note: The link between the 2 PTQ modules can also be established using an Ethernet switch. In that case, the user can transfer the module configuration without unplugging the cable. This solution is also used when the distance between the 2 PACs is too important.
Data used by the PTQ_Monitor DFB
1. Data circulating through the Profibus network
•
ProfibusCRC32: Profibus Master configurationThis word describes the configuration of the Profibus parameters and of the slave devices.
•
PTQModuleCRC32: PTQ-DPPMV1 configuration.This word describes the configuration of the PTQ module (mapping, and so on).
•
Profibus Master Operating StateThis word describes the status of the master module.
0x0000 Offline 0x4000 Stop 0x8000 Clear 0xC000 Operate
•
ProfibusMasterModuleStatus: Profibus master module’s operating status Bit 2Application Status
0 - Application Stopped 1 - Application Running
Bit 8 Data exchange
0 - There is no data exchange with any of the assigned slaves
1 - There is Data Exchange with at least one of the assigned slaves
Bit 9
Slave input frozen/cleared
0 - A slaves inputs in the IN area are cleared in a slave is not in Data Exchange
1 - A slave's inputs in the IN area are frozen if a slave is not in Data Exchange
Bit 12 Reset
0 - No action
1 - A reset is requested by the PROFIBUS Master module because a new database has been downloaded
•
HSBY Passive Status (Byte) – from Profibus interfaceBit 0 = PA
This bit indicates the state of the local master.
0 - Active master. Master is controlled by the Primary PAC
1 - Passive master. Master controlled by the Standby PAC
Bit 1 = SO
This bit indicates if the local master recognizes any of its assigned slaves as
"offline".
0 - At least one slave is "offline"
1 - All slaves OK
Bit 2 = CE
This bit indicates if the local master has recognized an exception response.
0 - No exception response active 1 - At least one exception response active
Bit 3 = DB
This bit indicates if the local master has detected a database mismatch.
0 - Database OK 1 - Database mismatch
Bit 4 = OD
This bit indicates when the data in the output data area of the DPRAM is updated after a switch over.
0 - Output data is not updated
1 - Output data is updated (Once this bit is set, it remains set for the remaining session until the any bus is either reset or HSBY state changes to "Not Connected") Bit 5 – 6 = not used
Bit 7 = COM
This bit indicates if the counterpart is present
0 - Counterpart not present 1 - Counterpart is present
•
HSBY Passive number of slaves (Byte) - from PROFIBUS interface Slave number seen by the Passive module•
HSBY Active Status (Byte) - from PROFIBUS interfaceBit 7 = HS
This bit indicates that the Hot- standby functionality is enabled.
0 HSBY disabled. Module operates as "stand alone" master or HSBY state equals "Not connected".
1 HSBY enabled
2. Data circulating through UDP mailer
The data available via UDP mailer only apply to the Passive module. It is identical to the data found on Profibus network:
•
HSBY Passive Status UDP - from UDP HSBY Server•
HSBY Passive number of slaves UDP - from UDP HSBY Server•
HSBY Passive PROFIBUS CRC32 UDP - from UDP HSBY Server•
HSBY Passive User Configuration CRC32 UDP - from UDP HSBY Server3. Operation
The Active PTQ module is declared non-operational in the following cases:
•
exception response•
application discrepancy•
inactive Hot-Standby system•
module in “Run” state•
loss of communication with the slave devices•
Master Operating State equals “ 0xC000=Operate”The Passive PTQ module is declared non-operationel in the following cases:
•
Exception response (Profibus and UDP) and Passive_number_of_slaves_UDP equals 0•
missing Counter part (Profibus and UDP) and Passive_number_of_slaves_UDP equals 0•
module in Active mode and Passive_number_of_slaves_UDP equals 0The Ethernet link which supports the UDP service is also monitored. If the status word PTQ_Passive_UDP equals 0, we consider the link as non-operational
In short, our DFB asks for a switchover when the Active module is non-operational and the Passive one is operating normally.
While implementing the Hot-Standby system, this DFB is used as many times as there are PTQ modules.
Switchover Management
Defaults Synthesis
Synthesis Fault NOE Module BOOL Faulty_NOE Synthesis Fault PTQ module BOOL Faulty_PTQ
Synthesis Fault Scada BOOL Faulty_SCADA Fault Mask word WORD Fault_Mask
Fault_Synth INT Synthesis Fault Word Fault BOOL OS Versions Mismatch SYNTH_FAULT
This block aims at processing the faults that would lead to a switchover. We find in inputs the results of the NOE and PTQ modules failure detection. “Faulty_SCADA” is an input pin in the case of the communication between the SCADA and the PAC is monitored.
This DFB also processes:
•
Battery events %S67 = application memory card battery
%S68 = processor battery
%S75 = data storage memory card battery
•
CPU non-operating %S12 = CPU running
•
General In-Rack I/O non-operating %S119 = event of one or several I/O modules in the rack
•
Slots 3 to 10 non-operating %SW180 = operating status of Quantum modules installed on station 1 The faults processing is performed using the mask value set on the input pin
“Fault_Mask”. This mask allows to select which event to take into account according to the configuration and the user’s settings.
Each exception corresponds to one bit of the “Fault_Synthesis” word:
BIT Element monitored Bit 0 Battery Exception Bit 1 CPU Exception
Bit 2 General In-Rack I/O Exception Bit 3 Exception on Slot 3
Bit 4 Exception on Slot 4 Bit 5 Exception on Slot 5 Bit 6 Exception on Slot 6 Bit 7 Exception on Slot 7 Bit 8 Exception on Slot 8 Bit 9 Exception on Slot 9 Bit 10 Exception on Slot 10
Bit 11 Ethernet Adapter(s) NOE Exception Bit 12 PROFIBUS Adapter(s) PTQ Exception Bit 13 SCADA Exception
The result of this synthesis is saved in a word and set as an output on the
“Fault_Synth_Plc” pin. If there is at least one exception response, the output pin
“Fault” is set to 1.
During the implementation of the system, this block is used twice: one for the Primary PAC and one for the Standby PAC.
In order to be able to compute the status of several NOE or PTQ modules, logical
“OR” and “AND” processing DFBs have been created:
BOOL FLT_NOE_1 BOOL
Switch Management
INT PRIM_DIAG Synthesis Fault word Standby INT STBY_DIAG
Switchover Number Reset BOOL SWITCH_NB_Reset SWITCH_NB UNIT Switchover request
Manual Switchover BOOL FORCE FORCE BOOL Manual Switchover
Synthesis Fault word Primary
SWITCH_MANAG
The “Switch_Manag” DFB manages and counts switchover queries. The switchover approval is computed from the Primary and Standby PACs diagnosis coming from the
“Fault_Synthesis” DFBs as seen above.
A switchover is allowed if:
•
The Standby PAC diagnosis is OK.•
More than 30s elapsed since last switchover.Note: The time delay before the switchover takes place can be adjusted using variables of the DFB (Delay_Time_Before_Switchover). This delay is set to 1s by default.
The switchover counter can be reset using the input pin “Switch_N_Reset”.
For maintenance reasons, the input pin FORCE allows a manual switchover of the system.
During the implementation of a Quantum Hot-Standby system, this block is used only once.
Remote I/Os
The use of Remote I/Os in a Hot-Standby system allows to work with redundant I/Os.
It is important to configure the “drop hold up time” according to the cycle time and to the application. This parameter is the time during which I/O values are maintained while a switchover occurs.
The Remote I/O stations are monitored using the following system words
%SW535
This word stores the start-up error code. This word is always set to 0 when the system is running; in the event of error, the PLC does not start up, but generates a stop status code.
%SW542 to %SW544
These words are the global communication error words.
Dedicated to the global station. That means these words can refer to Primary PAC as well as Standby PAC.
%SW545 to %SW640
These words are used to describe the status of the
decentralized stations. Three status words are used for each station.
Our Remote I/Os are configured on the Drop2. We therefore use the following system words:
%SW548: displays the global communication status for station 2
%SW545.0 to 7 = retry totalizer counter
%SW545.8 to 11 = lost communications counter
%SW545.13 = 1, communication on cable B operating correctly
%SW545.14 = 1, communication on cable A operating correctly
%SW545.15 = 1, communication operating correctly
%SW549: global event totals for cable A station 2
most significant bit: counts the errors detected
least significant bit: counts "non responses".
%SW550: global event totals for cable B station 2
most significant bit: counts the errors detected
least significant bit: counts "non responses".
Switchover Time
Remote Pac is Primary BOOL Remote_is_Primary Sw_Timer TIME Switchover Time This Pac is Primary BOOL This_is_Prima
Switch_Over_Time
The time gap during the switchover is a very important feature of the Hot-Standby system. A DFB has been defined to measure this time. The principle is based on the measurement of the time when the Primary PAC loses its Primary status and when the Standby turns Primary. This block, placed in the section 0, processes the system word %SW61 information and uses the ITCNTRL block function which allows event time measurements. The accuracy of the switchover time depends on the PAC scan time, for more accuracy, other measurement can be performed as described in the performance chapter.