Using State Change Triggers to Model Dependent Events with Delay in BlockSim 8
In some systems, the components are not independent; instead, the status of one component depends on that of other components. Load sharing components and standby components are the two typical dependent components. In practical application, load sharing events typically do not involve any delay. When a component fails in a load sharing configuration, its load is automatically distributed to other working components immediately. However, for standby events or other kinds of triggered events, a delay is very common in industrial fields. For example, consider two generators in a standby configuration where the primary generator is operating and the secondary one is in a standby state. If the primary generator fails, it takes some time to turn the secondary one on. In this article, we will focus on modeling dependent events with delays.
In BlockSim 8, it is easy to model a simple standby with delay configuration using a standby container. Within the standby container, we can add a switch, as shown next:
In the switch window, we can set the delay time directly.
However, standby containers are limited in that they can be used to model only simple standby configurations. They cannot model systems with complex configurations, or scenarios where the failure of a component will result in the deactivation of other components in the same system. For example, consider the system below. When component A fails, D is turned off immediately; when component A is restored, D is turned on after A has been running again for 5 hours. Similarly, when B fails, E is turned off immediately; when B is restored, E is turned on again with a delay of 5 hours.
Obviously, a standby container cannot model this system. Instead, we can use BlockSim 8's flexible new state change triggers to model this type of system. If you have BlockSim 8 installed on your computer, you can download and view the example file (5.63 MB, *.rsrp) here.
Let’s assume that components A and B follow a Weibull failure distribution with beta = 1.5 and eta = 100 hours. For the sake of simplicity, we will assume that components C, D and E cannot fail. The repair time for components A and B is 10 hours, and the delay for activating component D or E again after component A or B has been restored is 5 hours. We model the delay in this way: For each trigger event with a delay, we add an extra block for it and set the delay time as the operating time of that block. For example, in this system there is a delay in turning on block D when block A is restored. To model this, the diagram contains an extra block named D_delay. The initial status of extra block D_delay is off. When block A is restored, a state change trigger turns on block D_delay, which "operates" for 5 hours (the specified delay time). After 5 hours, a state change trigger turns on block D. We use the same logic, this time with an extra block called E_delay, to model the delay between restoring block B and turning on block E. To make sure that the extra blocks do not affect the original system, we connect them in parallel with the original system.
The settings for each block are as follows:
- Block A belongs to maintenance group MG_A.
- Block B belongs to maintenance group MG_B.
- Block D_delay:
- Normal failure distribution with mean = 5 and standard deviation = 0.00001 (ensuring that it runs 5 hours).
- CM duration = 0 (immediate repair).
- Belongs to maintenance group MG_D_delay.
- Initial state of the block is off (ensuring that the block does not operate unless it is turned on by a state change trigger).
- State upon repair is always off (ensuring that when the block is repaired after a failure, it returns to the off state).
- If any item from maintenance group MG_A is restored, this block is activated.
- Block E_delay has the same settings as D_delay, except that it belongs to maintenance group MG_E_delay and is activated if any item from maintenance group MG_B is restored.
- Block D:
- Initial state of the block is on (ensuring that the block is operating when simulation begins).
- State upon repair is always on (ensuring that when the block is repaired after a failure, it returns to the on state).
- If any item from maintenance group MG_A goes down, this block is deactivated.
- If any item from maintenance group MG_D_delay goes down, this block is activated.
- Block E has the same settings as block D, except that it is deactivated if any item from maintenance group MG_B goes down and is activated if any item from maintenance group MG_E_delay goes down.
Run a single simulation of the diagram above for mission time = 250 hours, using a seed of 5. The figure below shows the behavior of each block.
- At 73.677 hours, block A fails. This failure turns off block D . Block A is restored 10 hours later, at 83.677 hours.
- At 83.677 hours, the restoration of block A activates block D_delay.
- Block D_delay "operates" for 5 hours and "fails" at 88.677 hours.
- The "failure" of D_delay at 88.677 hours activates block D. In other words, block D is turned off at 73.677 hours due to the failure of A and is reactivated 15 hours later, which is 5 hours later than the restoration of block A.
- Similar behaviors are observed for block E due to block B's failure at 164.954 hours and for block D again at 193.904 hours.
Note: If you created this diagram on your own rather than viewing the example file, your simulation results may vary slightly from those shown here. Using a seed ensures repeatability of results for a given diagram by generating the same stream of random numbers. However, the order of the utilizations of the stream may differ depending on the way the diagram was constructed. For example, two people may have projects containing identical diagrams using blocks A and B. If in one diagram, A was created before B, A will take the first random value from the stream and B will take the second. If the other person (in the other project) created the same diagram but created B before A, B will take the first random value from the stream and A will take the second, thus yielding potentially different answers, even though both analysts may have used the same seed in simulation.
In this article, we presented a way to use state change triggers in BlockSim 8 to model dependent events with delays. The state change trigger is a powerful feature. With proper modeling skill, it can be used to model numerous complex systems and scenarios. For more information on using state change triggers, please visit http://www.ReliaWiki.org/index.php/State_Change_Triggers.