Example Using SCT for Standby Rotation

From ReliaWiki

Jump to: navigation, search


This example also appears in the System Analysis Reference book.

This example illustrates the use of state change triggers in BlockSim (Version 8 and above) by using a simple standby configuration. Note that this example could also be done using the standby container functionality in BlockSim.

More specifically, the following settings are illustrated:

  1. State Upon Repair: Default OFF unless SCT overridden
  2. Activate a block if any item from these associated maintenance group(s) goes down

Problem Statement

Assume three devices A, B and C in a standby redundancy (or only one unit is needed for system operation). The system begins with device A working. When device A fails, B is turned on and repair actions are initiated on A. When B fails, C is turned on and so forth.

BlockSim Solution

The BlockSim model of this system is shown in the figure below.

  • The failure distributions of all three blocks follow a Weibull distribution with Beta = 1.5 and Eta = 1,000 hours.
  • The repair distributions of the three blocks follow a Weibull distribution with Beta = 1.5 and Eta = 100 hours.
  • After repair, the blocks are "as good as new."

There are three maintenance groups, 2_A, 2_B and 2_C, set as follows:

  • Block A belongs to maintenance group 2_A.
    • It has a state change trigger.
      • The initial state is ON and the state upon repair is "Default OFF unless SCT overridden."
      • If any item from maintenance group 2_C goes down, then activate this block.


  • Block B belongs to maintenance group 2_B.
    • It has a state change trigger.
      • The initial state is OFF and the state upon repair is "Default OFF unless SCT overridden."
      • If any item from maintenance group 2_A goes down, then activate this block.


  • Block C belongs to maintenance group 2_C.
    • It has a state change trigger.
      • The initial state is OFF and the state upon repair is "Default OFF unless SCT overridden."
      • If any item from maintenance group 2_B goes down, then activate this block.


  • All blocks A, B and C are as good as new after repair.

System Events

The system event log for a single run through the simulation algorithm is shown in the Block Up/Down plot below, and is as follows:

  1. At 73 hours, Block A fails and activates Block B.
  2. At 183 hours, Block B fails and activates Block C.
  3. At 215 hours, Block B is done with repair. At this time, Block C is operating, so according to the settings, Block B is standby.
  4. At 238 hours, Block A is done with repair. At this time, Block C is operating. Thus Block A is standby.
  5. At 349 hours, Block C fails and activates Block A.
  6. At 396 hours, Block A fails and activates Block B.
  7. At 398 hours, Block C is done with repair. At this time, Block B is operating. Thus Block C is standby.
  8. At 432 hours, Block A is done with repair. At this time, Block B is operating. Thus Block A is standby.
  9. At 506 hours, Block B fails and activates Block C.
  10. At 515 hours, Block B is done with repair and stays standby because Block C is operating.
  11. At 536 hours, Block C fails and activates Block A.
  12. At 560 hours, Block A fails and activates Block B.
  13. At 575 hours, Block B fails and makes a request to activate Block C. However, Block C is under repair at the time. Thus when Block C is done with repair at 606 hours, the OFF setting is overridden and it is operating immediately.
  14. At 661 hours, Block C fails and makes a request to activate Block A. However, Block A is under repair at the time. Thus when Block A is done with repair at 699 hours, the OFF setting is overridden and it is operating immediately.
  15. Block B and Block C are done with repair at 682 hours and at 746 hours respectively. However, at these two time points, Block A is operating. Thus they are both standby upon repair according to the settings.


Personal tools
ReliaWiki.org
Create a book