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:
- State Upon Repair: Default ON unless SCT overridden
- Activate a block if any item from these associated maintenance group(s) goes down
- Deactivate a block if any item from these associated maintenance group(s) is restored
BlockSim Solution
Consider a 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 BlockSim modeling of this system is shown in the figure below.
- At 123 hours, Block P fails and activates Block S.
- At 186 hours ,Block S fails and is restored at 208 hours. According to the block's settings, it is ON upon repair.
- At 223 hours, Block S fails again.
- 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.
- At 439 hours, Block P fails and activates Block S.
- At 523 hours, Block P is restored and deactivates Block S.
- At 694 hours, Block P fails and activates Block S.
- 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.
- At 788 hours, Block P fails and activates Block S.
- At 845 hours, Block P is restored and deactivates Block S.
Example 2
This example is used to illustrate the following options in SCT:
- State Upon Repair: Default ON unless SCT overridden
- Deactivate a block if any item from these associated maintenance group(s) goes down
- Activate a block if any item from these associated maintenance group(s) is restored
BlockSim Solution
Consider a system is shown in the figure below.
Block A fails every 350 hours and the duration for the repair action is 100 hours. It is restored as good as new. 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 repair action is 100 hours too. It is restored as good as new. 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 D fails every 330 hours and the duration for repair action is 150 hours too. It is restored as good as new. 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 A, C and D all are as good as new after repair.
Block Up/Down Plot
The system behavior for simulation of 1200 hours durations is shown in Figure below and explained next.
- At 300 and at 330, Block C and D fail respectively.
- At 350, Block A fails, it brings 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 Block C is done with repair, the trigger will overwrite the default setting (default ON unless overridden) of Block C and C is stay OFF upon repair.
- At 450, Block A is restored, which activate Block B and C. Block D is still down for repair at this point, thus nothing happen to Block D.
- At 480, Block D is restored. According to setting, D is ON upon repair.
- At 750, Block C fails.
- At 800, Block A fails, and deactivates Block B and D. And it also put a request to turn Block C OFF. However, Block C is down for repair at this point, the state upon repair of Block C is overridden. Thus when Block C is done with repair at 850, it keeps stay OFF.
- At 900, A is restored, and activates Block B, C and D.
- From 910 to 1060, Block D fails and get repair. There is not trigger in this period, thus it is ON upon repair.