BlockSim Example: Default OFF unless SCT Overridden
Jump to navigation
Jump to search
 |
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 purpose of this example is to illustrate how the following options in BlockSim's State Change Triggers affect simulation:
- State Upon Repair: Default OFF unless SCT overridden
- Activate a block if any item from these associated maintenance group(s) is restored
- 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) goes down
- Deactivate a block if any item from these associated maintenance group(s) is restored
Problem Statement
Consider the system shown in the 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 a Weibull distribution with Beta = 1.5 and Eta = 100 for reliability. Blocks A1 and C have a Weibull distribution with Beta = 1.5 and Eta = 100 for the repair action. Block B has Weibull a distribution with Beta = 1.5 and Eta = 150 for the repair action. Block A2 has a Weibull distribution with Beta = 1.5 and Eta = 200 for the repair action. All blocks are as good as new after repair.
Block Up/Down Plot
The system event log, for a simulation of 820 hours, is shown in the figure below and explained next
- At 7 hours, Block B fails and activates Block C.
- At 50 hours, Block C fails and the repair is finished at 125 hours. According to its settings, Block C is OFF upon repair.
- At 71 hours, Block A2 fails.
- At 214 hours, Block B is restored. It fails again at 254 hours and activates Block C at that point.
- At 276 hours, Block A1 fails, and makes a request to deactivate Block A2. However, Block A2 is down for repair at this time. Nothing happens.
- At 363 hours, Block B is restored, deactivating Block C.
- At 376 hours, Block A1 is restored, and makes a request to activate Block A2. However, Block A2 is down for repair at this time. The state upon repair of Block A2 (Default OFF unless SCT overridden) is overridden. Thus when it gets repaired at 432 hours, it is ON.
- At 404 hours, Block B fails and activates Block C.
- At 461 hours, Block A1 fails and deactivates Block A2.
- At 483 hours, Block C fails.
- At 566 hours, Block B is restored.
- At 585 hours, Block B fails and makes a request to activate Block C. However, Block C is down for repair at this time. The state upon repair of Block C (Default OFF unless SCT overridden) is overridden. Thus when it gets repaired at 625 hours, it is ON.
- At 630 hours, Block A1 is restored and activates Block A2.
- At 631 hours, Block B is restored and deactivates Block C.
- At 647 hours, Block A2 fails.
- At 670 hours, Block B fails and activates Block C.
- At 700 hours, Block A1 fails and makes 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 repaired at 740 hours, it is OFF.
- At 770 hours, Block A1 is restored and activates Block A2.
- At 780 hours, Block C is restored. According to setting, it is OFF upon repair.
- At 802 hours, Block A2 fails
