BlockSim Example: Default OFF unless SCT Overridden

Default OFF unless SCT Overridden Example

Purposes

The purposes of this example are to illustrate the following options in SCT:

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

Description

Consider a system shown in Figure below:

Block A1 belongs to maintenance group A1.

Block A2 has state change triggers. Its initial state is ON, and the state upon repair is "Default OFF unless SCT overridden". If any item from maintenance group A1 goes down, then deactivate this block; if any item from the maintenance group A1 is restored, then activate this block.

Block B belong to maintenance group B.

Block C has state change triggers. Its initial state is OFF, and the state upon repair is "Default OFF unless SCT overridden". If any item from maintenance group B goes down, then activate this block; if any item from maintenance group B is restored, then deactivate this block.

All blocks A1, A2, B and C have Weibull distribution with Beta =1.5 and Eta = 100 for reliability. Block A1 and C have Weibull distribution with Beta = 1.5 and Eta = 100 for repair action. Block B has Weibull distribution with Beta =1.5 and Eta = 150 for repair action. Block A2 has Weibull distribution with Beta = 1.5 and Eta = 200 for repair action.  All blocks are as good as new after repair.

Block Up/Down plot

The system behavior for simulation of 820 hours durations (seed:23) is shown in Figure below and explained next.

1. At 7, Block B fails and activates Block C.
   
2. At 50, Block C fails and gets repair at 125. According to setting, Block C is OFF upon repair.
   
3. At 71, Block A2 fails.
   
4. At 214, Block B is restored. And it fails again at 254 and activates Block C at that point.
   
5. At 276, Block A1 fails, puts a request to deactivate Block A2. However, Block A2 is down for repair at this time. Nothing happens.
   
6. At 363, Block B is restored, deactivates Block C.
7. At 376, Block A1 is restored, and puts a request to activate Block A2. However, Block A2 is down for repair at this time. The state upon repair of Block A2 is overridden (default OFF). Thus when it gets repair at 432, it is ON upon repair.
   
8. At 404, Block B fails and activates Block C.
9. At 461, Block A1 fails and deactivates Block A2.
10. At 483, Block C fails.
11. At 566, Block B is restored.
12. At 585, Block B fails and puts a request to activate Block C. However, Block C is down for repair at this time. The state upon repair of Block C is overridden (default OFF), thus when it gets repair at 625, it is ON upon repair.
13. At 631, Block B is restored and deactivates Block C.
14. At 630, Block A1 is restored and activates Block A2.
15. At 647, Block A2 fails.
16. At 670, Block B fails and activates Block C.
17. At 700, Block A1 fails, puts a request to deactivate Block A2. Block A2 is down for repair at this time, and furthermore, the default setting of state for Block A2 upon repair is OFF. Thus when Block A2 gets repair at 740, it is OFF.
18. At 770, Block A1 is restored and activates Block A2.
19. At 780, Block C gets repairs. According to setting, it is OFF upon repair.
20. At 802, Block A2 fails