Repairable Systems Analysis Through Simulation - Revision history

Lisa Hacker at 18:48, 10 March 2023

2023-03-10T18:48:06Z

Sharon Honecker: /* Probabilistic View, Simple Series */ changed R(T,t) to R(t|T)

2017-02-08T19:11:59Z

Probabilistic View, Simple Series: changed R(T,t) to R(t|T)

← Older revision		Revision as of 19:11, 8 February 2017
Line 89:		Line 89:
	To obtain a conditional time, the Weibull conditional reliability function is given by:		To obtain a conditional time, the Weibull conditional reliability function is given by:

	::<math>R(T,t)=\frac{R(T+t)}{R(T)}=\frac{{{e}^{-{{\left( \tfrac{T+t}{\eta } \right)}^{\beta }}}}}{{{e}^{-{{\left( \tfrac{T}{\eta } \right)}^{\beta }}}}}\,\!</math>		::<math>R(t\|T)=\frac{R(T+t)}{R(T)}=\frac{{{e}^{-{{\left( \tfrac{T+t}{\eta } \right)}^{\beta }}}}}{{{e}^{-{{\left( \tfrac{T}{\eta } \right)}^{\beta }}}}}\,\!</math>

	Or:		Or:

	::<math>R(T,t)={{e}^{-\left[ {{\left( \tfrac{T+t}{\eta } \right)}^{\beta }}-{{\left( \tfrac{T}{\eta } \right)}^{\beta }} \right]}}\,\!</math>		::<math>R(t\|T)={{e}^{-\left[ {{\left( \tfrac{T+t}{\eta } \right)}^{\beta }}-{{\left( \tfrac{T}{\eta } \right)}^{\beta }} \right]}}\,\!</math>

	The random time would be the solution for <math>t\,\!</math> for <math>R(T,t)={{U}_{R}}[0,1]\,\!</math>.		The random time would be the solution for <math>t\,\!</math> for <math>R(t\|T)={{U}_{R}}[0,1]\,\!</math>.

	To illustrate the sequence of events, assume a single block with a failure and a repair distribution. The first event, <math>{{E}_{{{F}_{1}}}}\,\!</math>, would be the failure of the component. Its first time-to-failure would be a random number drawn from its failure distribution, <math>{{T}_{{{F}_{1}}}}\,\!</math>. Thus, the first failure event, <math>{{E}_{{{F}_{1}}}}\,\!</math>, would be at <math>{{T}_{{{F}_{1}}}}\,\!</math>. Once failed, the next event would be the repair of the component, <math>{{E}_{{{R}_{1}}}}\,\!</math>. The time to repair the component would now be drawn from its repair distribution, <math>{{T}_{{{R}_{1}}}}\,\!</math>. The component would be restored by time <math>{{T}_{{{F}_{1}}}}+{{T}_{{{R}_{1}}}}\,\!</math>. The next event would now be the second failure of the component after the repair, <math>{{E}_{{{F}_{2}}}}\,\!</math>. This event would occur after a component operating time of <math>{{T}_{{{F}_{2}}}}\,\!</math> after the item is restored (again drawn from the failure distribution), or at <math>{{T}_{{{F}_{1}}}}+{{T}_{{{R}_{1}}}}+{{T}_{{{F}_{2}}}}\,\!</math>. This process is repeated until the end time. It is important to note that each run will yield a different sequence of events due to the probabilistic nature of the times. To arrive at the desired result, this process is repeated many times and the results from each run (simulation) are recorded. In other words, if we were to repeat this 1,000 times, we would obtain 1,000 different values for <math>{{E}_{{{F}_{1}}}}\,\!</math>, or <math>\left[ {{E}_{{{F}_{{{1}_{1}}}}}},{{E}_{{{F}_{{{1}_{2}}}}}},...,{{E}_{{{F}_{{{1}_{1,000}}}}}} \right]\,\!</math>.		To illustrate the sequence of events, assume a single block with a failure and a repair distribution. The first event, <math>{{E}_{{{F}_{1}}}}\,\!</math>, would be the failure of the component. Its first time-to-failure would be a random number drawn from its failure distribution, <math>{{T}_{{{F}_{1}}}}\,\!</math>. Thus, the first failure event, <math>{{E}_{{{F}_{1}}}}\,\!</math>, would be at <math>{{T}_{{{F}_{1}}}}\,\!</math>. Once failed, the next event would be the repair of the component, <math>{{E}_{{{R}_{1}}}}\,\!</math>. The time to repair the component would now be drawn from its repair distribution, <math>{{T}_{{{R}_{1}}}}\,\!</math>. The component would be restored by time <math>{{T}_{{{F}_{1}}}}+{{T}_{{{R}_{1}}}}\,\!</math>. The next event would now be the second failure of the component after the repair, <math>{{E}_{{{F}_{2}}}}\,\!</math>. This event would occur after a component operating time of <math>{{T}_{{{F}_{2}}}}\,\!</math> after the item is restored (again drawn from the failure distribution), or at <math>{{T}_{{{F}_{1}}}}+{{T}_{{{R}_{1}}}}+{{T}_{{{F}_{2}}}}\,\!</math>. This process is repeated until the end time. It is important to note that each run will yield a different sequence of events due to the probabilistic nature of the times. To arrive at the desired result, this process is repeated many times and the results from each run (simulation) are recorded. In other words, if we were to repeat this 1,000 times, we would obtain 1,000 different values for <math>{{E}_{{{F}_{1}}}}\,\!</math>, or <math>\left[ {{E}_{{{F}_{{{1}_{1}}}}}},{{E}_{{{F}_{{{1}_{2}}}}}},...,{{E}_{{{F}_{{{1}_{1,000}}}}}} \right]\,\!</math>.

Miklos Szidarovszky: /* Additional Rules and Assumptions for Standby Containers */

2017-01-03T20:47:52Z

Additional Rules and Assumptions for Standby Containers

← Older revision		Revision as of 20:47, 3 January 2017
Line 984:		Line 984:
	::1) A container will only attempt to switch if there is an available non-failed item to switch to. If there is no such item, it will then switch if and when an item becomes available. The switch will cancel the action if it gets restored before an item becomes available.		::1) A container will only attempt to switch if there is an available non-failed item to switch to. If there is no such item, it will then switch if and when an item becomes available. The switch will cancel the action if it gets restored before an item becomes available.
	:::a) As an example, consider the case of unit <math>A\,\!</math> failing active while unit <math>B\,\!</math> failed in a quiescent mode. If unit <math>B\,\!</math> gets restored before unit <math>A\,\!</math>, then the switch will be initiated. If unit <math>A\,\!</math> is restored before unit <math>B\,\!</math>, the switch action will not occur.		:::a) As an example, consider the case of unit <math>A\,\!</math> failing active while unit <math>B\,\!</math> failed in a quiescent mode. If unit <math>B\,\!</math> gets restored before unit <math>A\,\!</math>, then the switch will be initiated. If unit <math>A\,\!</math> is restored before unit <math>B\,\!</math>, the switch action will not occur.
	::2) If the container switch is failed and a switching action is required, the switching action will occur after the switch has been restored if it is still required (i.e., if the active unit is still failed).		::2) In cases where not all active units are required, a switch will only occur if the failed combination causes the container to fail.
	::3) If a switch fails during the delay time of the switching action based on the reliability distribution (quiescent failure mode), the action is still carried out unless a failure based on the switch probability/restarts occurs when attempting to switch.		:::a) For example, if <math>A\,\!</math>, <math>B\,\!</math>, and <math>C\,\!</math> are in a container for which one unit is required to be operating and <math>A\,\!</math> and <math>B\,\!</math> are active with <math>C\,\!</math> on standby, then the failure of either <math>A\,\!</math> or <math>B\,\!</math> will not cause a switching action. The container will switch to <math>C\,\!</math> only if both <math>A\,\!</math> and <math>B\,\!</math> are failed.
	::4) During switching events, the change from the operating to quiescent distribution (and vice versa) occurs at the end of the delay time.		::3) If the container switch is failed and a switching action is required, the switching action will occur after the switch has been restored if it is still required (i.e., if the active unit is still failed).
	::5) The option of whether components operate while the system is down is defined at component level now (This is different from BlockSim 7, in which this option of the contained items inherit from container). Two rules here:		::4) If a switch fails during the delay time of the switching action based on the reliability distribution (quiescent failure mode), the action is still carried out unless a failure based on the switch probability/restarts occurs when attempting to switch.
			::5) During switching events, the change from the operating to quiescent distribution (and vice versa) occurs at the end of the delay time.
			::6) The option of whether components operate while the system is down is defined at component level now (This is different from BlockSim 7, in which this option of the contained items inherit from container). Two rules here:
	:::a) If a path inside the container is down, blocks inside the container that are in that path do not continue to operate.		:::a) If a path inside the container is down, blocks inside the container that are in that path do not continue to operate.
	:::b) Blocks that are up do not continue to operate while the container is down.		:::b) Blocks that are up do not continue to operate while the container is down.
	::6) A switch can have a repair distribution and maintenance properties without having a reliability distribution.		::7) A switch can have a repair distribution and maintenance properties without having a reliability distribution.
	:::a) This is because maintenance actions are performed regardless of whether the switch failed while waiting to switch (reliability distribution) or during the actual switching process (fixed probability).		:::a) This is because maintenance actions are performed regardless of whether the switch failed while waiting to switch (reliability distribution) or during the actual switching process (fixed probability).
	::7) A switch fails during switching when the restarts are exhausted.		::8) A switch fails during switching when the restarts are exhausted.
	::8) A restart is executed every time the switch fails to switch (based on its fixed probability of switching).		::9) A restart is executed every time the switch fails to switch (based on its fixed probability of switching).
	::9) If a delay is specified, restarts happen after the delay.		::10) If a delay is specified, restarts happen after the delay.
	::10) If a container brings the system down, the container is responsible for the system going down (not the blocks inside the container).		::11) If a container brings the system down, the container is responsible for the system going down (not the blocks inside the container).

	===Load Sharing Containers===		===Load Sharing Containers===

Miklos Szidarovszky: /* Additional Rules and Assumptions for Standby Containers */

2017-01-03T20:07:19Z

Additional Rules and Assumptions for Standby Containers

← Older revision		Revision as of 20:07, 3 January 2017
Line 984:		Line 984:
	::1) A container will only attempt to switch if there is an available non-failed item to switch to. If there is no such item, it will then switch if and when an item becomes available. The switch will cancel the action if it gets restored before an item becomes available.		::1) A container will only attempt to switch if there is an available non-failed item to switch to. If there is no such item, it will then switch if and when an item becomes available. The switch will cancel the action if it gets restored before an item becomes available.
	:::a) As an example, consider the case of unit <math>A\,\!</math> failing active while unit <math>B\,\!</math> failed in a quiescent mode. If unit <math>B\,\!</math> gets restored before unit <math>A\,\!</math>, then the switch will be initiated. If unit <math>A\,\!</math> is restored before unit <math>B\,\!</math>, the switch action will not occur.		:::a) As an example, consider the case of unit <math>A\,\!</math> failing active while unit <math>B\,\!</math> failed in a quiescent mode. If unit <math>B\,\!</math> gets restored before unit <math>A\,\!</math>, then the switch will be initiated. If unit <math>A\,\!</math> is restored before unit <math>B\,\!</math>, the switch action will not occur.
	::2~~) In cases where not all active units are required, a switch will only occur if the failed combination causes the container to fail.~~		::2) If the container switch is failed and a switching action is required, the switching action will occur after the switch has been restored if it is still required (i.e., if the active unit is still failed).
	:::a) For example, if <math>A\,\!</math>, <math>B\,\!</math> and <math>C\,\!</math> are in a container for which one unit is required to be operating and <math>A\,\!</math> and <math>B\,\!</math> are active with <math>C\,\!</math> on standby, then the failure of either <math>A\,\!</math> or <math>B\,\!</math> will not cause a switching action. The container will switch to <math>C\,\!</math> only if both <math>A\,\!</math> and <math>B\,\!</math> are failed.		::3) If a switch fails during the delay time of the switching action based on the reliability distribution (quiescent failure mode), the action is still carried out unless a failure based on the switch probability/restarts occurs when attempting to switch.
	~~::3~~) If the container switch is failed and a switching action is required, the switching action will occur after the switch has been restored if it is still required (i.e., if the active unit is still failed).		::4) During switching events, the change from the operating to quiescent distribution (and vice versa) occurs at the end of the delay time.
	::4) If a switch fails during the delay time of the switching action based on the reliability distribution (quiescent failure mode), the action is still carried out unless a failure based on the switch probability/restarts occurs when attempting to switch.		::5) The option of whether components operate while the system is down is defined at component level now (This is different from BlockSim 7, in which this option of the contained items inherit from container). Two rules here:
	::5) During switching events, the change from the operating to quiescent distribution (and vice versa) occurs at the end of the delay time.
	::6) The option of whether components operate while the system is down is defined at component level now (This is different from BlockSim 7, in which this option of the contained items inherit from container). Two rules here:
	:::a) If a path inside the container is down, blocks inside the container that are in that path do not continue to operate.		:::a) If a path inside the container is down, blocks inside the container that are in that path do not continue to operate.
	:::b) Blocks that are up do not continue to operate while the container is down.		:::b) Blocks that are up do not continue to operate while the container is down.
	::7) A switch can have a repair distribution and maintenance properties without having a reliability distribution.		::6) A switch can have a repair distribution and maintenance properties without having a reliability distribution.
	:::a) This is because maintenance actions are performed regardless of whether the switch failed while waiting to switch (reliability distribution) or during the actual switching process (fixed probability).		:::a) This is because maintenance actions are performed regardless of whether the switch failed while waiting to switch (reliability distribution) or during the actual switching process (fixed probability).
	::8) A switch fails during switching when the restarts are exhausted.		::7) A switch fails during switching when the restarts are exhausted.
	::9) A restart is executed every time the switch fails to switch (based on its fixed probability of switching).		::8) A restart is executed every time the switch fails to switch (based on its fixed probability of switching).
	::10) If a delay is specified, restarts happen after the delay.		::9) If a delay is specified, restarts happen after the delay.
	::11) If a container brings the system down, the container is responsible for the system going down (not the blocks inside the container).		::10) If a container brings the system down, the container is responsible for the system going down (not the blocks inside the container).

	===Load Sharing Containers===		===Load Sharing Containers===

Richard House: /* Example Using P-F Interval */

2016-01-06T20:23:58Z

Example Using P-F Interval

← Older revision		Revision as of 20:23, 6 January 2016
Line 736:		Line 736:
	::#At 1800 <math>tu\,\!</math> the sixth scheduled inspection occurs. At this time the age of the component is 240 <math>tu\,\!</math>. This inspection does not lie in the P-F interval (from age 600 tu to 700 <math>tu\,\!</math>) and no approaching failure is detected.		::#At 1800 <math>tu\,\!</math> the sixth scheduled inspection occurs. At this time the age of the component is 240 <math>tu\,\!</math>. This inspection does not lie in the P-F interval (from age 600 tu to 700 <math>tu\,\!</math>) and no approaching failure is detected.

	[[Image:BS8.32.png\|center\|~~500px~~\|link=]]		[[Image:BS8.32.png\|center\|600px\|link=]]

	====Rules for PMs and Inspections====		====Rules for PMs and Inspections====

Richard House: /* Example Using Both Crews and Pools */

2016-01-06T20:23:22Z

Example Using Both Crews and Pools

← Older revision		Revision as of 20:23, 6 January 2016
Line 604:		Line 604:
	Consider the following example, using both crews and pools.		Consider the following example, using both crews and pools.

	[[Image:r19.png\|center\|~~350px~~\|link=]]		[[Image:r19.png\|center\|300px\|link=]]

	where:		where:

Richard House: /* Example Using Both Crews and Pools */

2016-01-06T20:22:58Z

Example Using Both Crews and Pools

← Older revision		Revision as of 20:22, 6 January 2016
Line 604:		Line 604:
	Consider the following example, using both crews and pools.		Consider the following example, using both crews and pools.

	[[Image:r19.png\|center\|~~400px~~\|link=]]		[[Image:r19.png\|center\|350px\|link=]]

	where:		where:
Line 612:		Line 612:
	And the crews are:		And the crews are:

	[[Image:r21.png\|center\|~~300px~~\|link=]]		[[Image:r21.png\|center\|400px\|link=]]

	While the spare pool is:		While the spare pool is:

	[[Image:r22.png\|center\|~~450px~~\|link=]]		[[Image:r22.png\|center\|500px\|link=]]

	The behavior of this system from 0 to 300 is shown graphically in the figure below.		The behavior of this system from 0 to 300 is shown graphically in the figure below.

Richard House: /* Explanation of the Crew Details */

2016-01-06T20:21:43Z

Explanation of the Crew Details

← Older revision		Revision as of 20:21, 6 January 2016
Line 464:		Line 464:
	Note that crew costs that are attributed to individual blocks can be obtained from the Blocks reports, as shown in the figure below.		Note that crew costs that are attributed to individual blocks can be obtained from the Blocks reports, as shown in the figure below.

	[[Image:BS8.19.png\|thumb\|center\|~~600px~~\|Allocation of crew costs.\|link=]]		[[Image:BS8.19.png\|thumb\|center\|650px\|Allocation of crew costs.\|link=]]

	====How BlockSim Handles Crews====		====How BlockSim Handles Crews====

Richard House: /* Illustrating Crew Use */

2016-01-06T20:21:14Z

Illustrating Crew Use

← Older revision		Revision as of 20:21, 6 January 2016
Line 437:		Line 437:
	The following figure shows an example of some of the possible crew results (details), which are presented next.		The following figure shows an example of some of the possible crew results (details), which are presented next.

	[[Image:BS8.18.png\|thumb\|center\|~~450px~~\|Crew results shown in the BlockSim's Simulation Results Explorer.\|link=]]		[[Image:BS8.18.png\|thumb\|center\|500px\|Crew results shown in the BlockSim's Simulation Results Explorer.\|link=]]

	====Explanation of the Crew Details====		====Explanation of the Crew Details====

Richard House: /* General Simulation Results */

2016-01-06T20:19:35Z

General Simulation Results

← Older revision		Revision as of 20:19, 6 January 2016
Line 105:		Line 105:

	The simulation settings are shown in the figure below.		The simulation settings are shown in the figure below.
	[[Image:8.7.gif\|center\|~~500px~~\|BlockSim simulation window.\|link=]]		[[Image:8.7.gif\|center\|600px\|BlockSim simulation window.\|link=]]

	===General===		===General===