BlockSim Example: Default ON unless SCT Overridden

New format available! This reference is now available in a new format that offers faster page load, improved display for calculations and images and more targeted search.

As of January 2024, this Reliawiki page will not continue to be updated. Please update all links and bookmarks to the latest references at BlockSim examples and BlockSim reference examples.

---

The examples illustrate, for BlockSim's State Change Triggers, how selecting the Default ON unless SCT overridden option in the State upon repair field affects simulation. Two cases are presented.

Example 1

This example is used to illustrate the following state change trigger options:

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

BlockSim Solution

Consider the system shown in the figure below:

• Block P is the primary device. It belongs to maintenance group P.
• Block S is the standby device. It has state change triggers. The initial state is OFF. If Block P goes down, then activate this block; if Block P is restored, then deactivate this block. The State Upon Repair is "Default ON unless SCT Overridden."
• Both Block P and Block S have a Weibull distribution with Beta = 1.5 and Eta = 100 for reliability and repair action.
• Both Block P and Block S are as good as new after repair.

Block Up/Down Plot

The system event log is shown in the figure below and explained next.

1. At 123 hours, Block P fails and activates Block S.
2. At 186 hours, Block S fails and is restored at 208 hours. According to the block's settings, it is ON upon repair.
3. At 223 hours, Block S fails again.
4. At 301 hours, Block P is restored, and put a request to deactivate Block S. However, Block S is down for repair at this point. The request overwrites the default state upon repair setting of Block S. Thus when Block S is done with repair at 385 hours, it is OFF.
5. At 439 hours, Block P fails and activates Block S.
6. At 523 hours, Block P is restored and deactivates Block S.
7. At 694 hours, Block P fails and activates Block S.
8. At 702 hours, Block S fails and the repair is finished at 775 hours. According to the block's settings, it is ON upon repair.
9. At 788 hours, Block P fails and activates Block S.
10. At 845 hours, Block P is restored and deactivates Block S.

Example 2

This example illustrates the following state change trigger options:

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

BlockSim Solution
Consider the system is shown in the figure below.

• Block A fails every 350 hours and the duration for the repair action is 100 hours. It belongs to maintenance group A.
• Block B cannot fail. It has state change triggers. The initial state is ON, and the state upon trigger is "Default On unless SCT overridden." If any item from maintenance group A goes down, this block is deactivated; if any item from maintenance group A is restored, this block is activated.
• Block C fails every 300 hours and the duration for the repair action is 100 hours. It is has state change triggers. The initial state is ON, and the state upon trigger is "Default On unless SCT overridden." If any item from maintenance group A goes down, this block is deactivated; if any item from maintenance group A is restored, this block is activated.
• Block D fails every 330 hours and the duration for repair action is 150 hours . It has state change triggers. The initial state is ON, and the state upon trigger is "Default On unless SCT overridden." If any item from maintenance group A goes down, this block is deactivated; if any item from maintenance group A is restored, this block is activated.
• Blocks A, C and D all are as good as new after repair.

Block Up/Down Plot
The system event log, for a duration of 1,200 hours, is shown in the figure below and explained next

1. At 300 hours and at 330 hours, Blocks C and D fail respectively.
   
2. At 350 hours, Block A fails. This brings the system down, turns Block B OFF and also puts a request to turn Block C OFF. However, Block C is down for repair at this time, thus after the repair on Block C is finished, the default setting of Block C (default ON unless overridden) will be overridden and it will stay OFF upon repair.
3. At 450 hours, Block A is restored, which activate Blocks B and C. Block D is still down for repair at this point, so nothing happens to Block D.
4. At 480 hours, Block D is restored. According to its settings, Block D is ON upon repair.
5. At 750 hours, Block C fails.
6. At 800 hours, Block A fails, and deactivates Blocks B and D. It also makes a request to turn Block C OFF. However, Block C is down for repair at this point, so the state upon repair of Block C is overridden. Thus when repair on Block C is finished at 850 hours, it stays OFF.
7. At 900 hours, Block A is restored, and activates Blocks B, C and D.
8. From 910 hours to 1060 hours, Block D fails and is repaired. There is no trigger in this period, so it is ON upon repair.