Additional Analyses - Revision history

Richard House: /* Throughput Analysis Options */

2016-01-05T23:19:29Z

Throughput Analysis Options

← Older revision		Revision as of 23:19, 5 January 2016
Line 110:		Line 110:

	<center>''' Throughput summary using weighted allocation across paths.'''</center>		<center>''' Throughput summary using weighted allocation across paths.'''</center>
	[[Image:weighted allocation summary.png\|center\|~~550px~~\|link=]]		[[Image:weighted allocation summary.png\|center\|650px\|link=]]

	If the '''Allocate equal share to all paths''' option is chosen, then 20 units will be sent to <math>B\,\!</math>, <math>C\,\!</math> and <math>D\,\!</math> regardless of their processing capacity, yielding the results shown in the table below.		If the '''Allocate equal share to all paths''' option is chosen, then 20 units will be sent to <math>B\,\!</math>, <math>C\,\!</math> and <math>D\,\!</math> regardless of their processing capacity, yielding the results shown in the table below.

	<center>''' Throughput summary using an equal allocation across paths.'''</center>		<center>''' Throughput summary using an equal allocation across paths.'''</center>
	[[Image:equal allocation summary.png\|center\|~~550px~~\|link=]]		[[Image:equal allocation summary.png\|center\|650px\|link=]]

	'''Send units to failed blocks''': Decide whether items should be sent to failed parts.		'''Send units to failed blocks''': Decide whether items should be sent to failed parts.
Line 129:		Line 129:

	<center>''' Scenario 3 summary with ''F'' and ''G'' having a limited blacklog and after one time unit.'''</center>		<center>''' Scenario 3 summary with ''F'' and ''G'' having a limited blacklog and after one time unit.'''</center>
	[[Image:limited backlog summary 1.png\|center\|~~550px~~\|link=]]		[[Image:limited backlog summary 1.png\|center\|650px\|link=]]

	<center>''' Scenario 3 summary with ''F'' and ''G'' having a limited backlog and after two time units.'''</center>		<center>''' Scenario 3 summary with ''F'' and ''G'' having a limited backlog and after two time units.'''</center>
	[[Image:limited backlog summary 2.png\|center\|~~550px~~\|link=]]		[[Image:limited backlog summary 2.png\|center\|650px\|link=]]

	Note that the blocks will never be able to process the backlog in this example. However, if we were to observe the system for a longer operation time and through failures and repairs of the other blocks, there would be opportunities for the blocks to process their backlogs and catch up. It is very important to note that when simulating a system with failures and repairs in BlockSim, you must define the block as one that operates through system failure if you wish for backlog to be processed. If this option is not set, the block will not operate through system failure and thus will not be able to process any backlog items when components that cause system failure (from an RBD perspective) fail.		Note that the blocks will never be able to process the backlog in this example. However, if we were to observe the system for a longer operation time and through failures and repairs of the other blocks, there would be opportunities for the blocks to process their backlogs and catch up. It is very important to note that when simulating a system with failures and repairs in BlockSim, you must define the block as one that operates through system failure if you wish for backlog to be processed. If this option is not set, the block will not operate through system failure and thus will not be able to process any backlog items when components that cause system failure (from an RBD perspective) fail.

Richard House: /* Example */

2015-12-22T21:48:30Z

Example

← Older revision		Revision as of 21:48, 22 December 2015
Line 146:		Line 146:
	Imagine a system where block A and block C each have a throughput of 300 units/hour, while block B (mirrored block) and block D each have a throughput of 100 units/hour.		Imagine a system where block A and block C each have a throughput of 300 units/hour, while block B (mirrored block) and block D each have a throughput of 100 units/hour.

	[[Image:mirrors_and_throughput1.png\|center\|]]		[[Image:mirrors_and_throughput1.png\|center\|link=]]

	If all the blocks are operating, then the system throughput is 300 units/hour, as each instance of block B is able to handle 100 units/hour.		If all the blocks are operating, then the system throughput is 300 units/hour, as each instance of block B is able to handle 100 units/hour.

	[[Image:mirrors_and_throughput2.png\|center\|]]		[[Image:mirrors_and_throughput2.png\|center\|link=]]

	If block B is down, then the system throughput becomes 100 units/hour, as block B is considered down at both locations.		If block B is down, then the system throughput becomes 100 units/hour, as block B is considered down at both locations.

Richard House: /* Throughput Analysis Options */

2015-12-22T21:46:50Z

Throughput Analysis Options

Richard House: /* Scenario 3 */

2015-12-22T21:45:06Z

Scenario 3

← Older revision		Revision as of 21:45, 22 December 2015
Line 71:		Line 71:
	Finally, consider the figure below where both <math>E\,\!</math> and <math>H\,\!</math> have failed.		Finally, consider the figure below where both <math>E\,\!</math> and <math>H\,\!</math> have failed.

	[[Image:9.3.png\|center\|500px\|Throughput RBD for Scenario 3.]]		[[Image:9.3.png\|center\|500px\|Throughput RBD for Scenario 3.\|link=]]

	Then:		Then:
Line 83:		Line 83:

	<center>'''Run summary for Scenario 3.'''</center>		<center>'''Run summary for Scenario 3.'''</center>
	[[Image:9.3t.png\|center\|400px\|]]		[[Image:9.3t.png\|center\|400px\|link=]]

	<center>'''Utilization summary for Scenario 3.</center>		<center>'''Utilization summary for Scenario 3.</center>
	[[Image:9.3t2.png\|center\|300px\|]]		[[Image:9.3t2.png\|center\|300px\|link=]]

	It can be easily seen that the bottlenecks in the system are the blocks <math>F\,\!</math> and <math>G\,\!</math>.		It can be easily seen that the bottlenecks in the system are the blocks <math>F\,\!</math> and <math>G\,\!</math>.

	==Throughput Analysis Options==<!-- THIS SECTION HEADER IS LINKED TO: Constant Throughput Example. IF YOU RENAME THE SECTION, YOU MUST UPDATE THE LINK. -->		==Throughput Analysis Options==<!-- THIS SECTION HEADER IS LINKED TO: Constant Throughput Example. IF YOU RENAME THE SECTION, YOU MUST UPDATE THE LINK. -->

Richard House: /* Scenario 2 */

2015-12-22T21:44:20Z

Scenario 2

← Older revision		Revision as of 21:44, 22 December 2015
Line 53:		Line 53:
	Now consider the figure below where it is assumed that block <math>E\,\!</math> has failed.		Now consider the figure below where it is assumed that block <math>E\,\!</math> has failed.

	[[Image:9.2.png\|center\|500px\|Throughput RBD for Scenario 2.]]		[[Image:9.2.png\|center\|500px\|Throughput RBD for Scenario 2.\|link=]]

	Then:		Then:
Line 66:		Line 66:

	<center>'''Run summary for Scenario 2.'''</center>		<center>'''Run summary for Scenario 2.'''</center>
	[[Image:9.2t.png\|center\|350px\|]]		[[Image:9.2t.png\|center\|350px\|link=]]

	===Scenario 3===		===Scenario 3===

Richard House: /* Scenario 1 */

2015-12-22T21:43:57Z

Scenario 1

← Older revision		Revision as of 21:43, 22 December 2015
Line 33:		Line 33:
	Consider the system shown in the figure below.		Consider the system shown in the figure below.

	[[Image:9.1.png\|center\|500px\|Throughput RBD for Scenario 1.]]		[[Image:9.1.png\|center\|500px\|Throughput RBD for Scenario 1.\|link=]]

	Blocks <math>A\,\!</math> through <math>I\,\!</math> produce a number of items per unit time as identified next to each letter (e.g., <math>A\,\!</math> : 100 implies <math>100\,\!</math> items per time unit for <math>A\,\!</math> ). The connections shown in the RBD show the physical path of the items through the process (or production line). For the sake of simplicity, also assume that the blocks can never fail and that items are routed equally to each path.		Blocks <math>A\,\!</math> through <math>I\,\!</math> produce a number of items per unit time as identified next to each letter (e.g., <math>A\,\!</math> : 100 implies <math>100\,\!</math> items per time unit for <math>A\,\!</math> ). The connections shown in the RBD show the physical path of the items through the process (or production line). For the sake of simplicity, also assume that the blocks can never fail and that items are routed equally to each path.
Line 48:		Line 48:

	<center>'''Run summary for Scenario 1.'''</center>		<center>'''Run summary for Scenario 1.'''</center>
	[[Image:9.1t.png\|center\|350px\|]]		[[Image:9.1t.png\|center\|350px\|link=]]

	===Scenario 2===		===Scenario 2===

Richard House: /* Throughput Analysis */

2015-12-22T21:42:54Z

Throughput Analysis

← Older revision		Revision as of 21:42, 22 December 2015
Line 6:		Line 6:
	In the prior sections, we concentrated on failure and repair actions of a system. In doing so, we viewed the system from a system/component up/down perspective. One could take this analysis a step further and consider system throughput as a part of the analysis. To define system throughput, assume that each component in the system processed (or made) something while operating. As an example, consider the case shown next with two components in series, each processing/producing 10 and 20 items per unit time (ipu) respectively.		In the prior sections, we concentrated on failure and repair actions of a system. In doing so, we viewed the system from a system/component up/down perspective. One could take this analysis a step further and consider system throughput as a part of the analysis. To define system throughput, assume that each component in the system processed (or made) something while operating. As an example, consider the case shown next with two components in series, each processing/producing 10 and 20 items per unit time (ipu) respectively.

	[[Image:10to20.png\|center\|150px\|]]		[[Image:10to20.png\|center\|150px\|link=]]

	In this case, the system configuration is not only the system's reliability-wise configuration but also its production/processing sequence. In other words, the first component processes/produces 10 ipu and the second component can process/produce up to 20 ipu. However, a block can only process/produce items it receives from the blocks before it. Therefore, the second component in this case is only receiving 10 ipu from the block before it. If we assume that neither component can fail, then the maximum items processed from this configuration would be 10 ipu. If the system were to operate for 100 time units, then the throughput of this system would be 1000 items, or <math>(100\cdot 10)\,\!</math>.		In this case, the system configuration is not only the system's reliability-wise configuration but also its production/processing sequence. In other words, the first component processes/produces 10 ipu and the second component can process/produce up to 20 ipu. However, a block can only process/produce items it receives from the blocks before it. Therefore, the second component in this case is only receiving 10 ipu from the block before it. If we assume that neither component can fail, then the maximum items processed from this configuration would be 10 ipu. If the system were to operate for 100 time units, then the throughput of this system would be 1000 items, or <math>(100\cdot 10)\,\!</math>.

Melinda Caroline at 21:29, 19 October 2015

2015-10-19T21:29:23Z

@@ Line 135: / Line 135: @@
 Note that the blocks will never be able to process the backlog in this example.  However, if we were to observe the system for a longer operation time and through failures and repairs of the other blocks, there would be opportunities for the blocks to process their backlogs and catch up.  It is very important to note that when simulating a system with failures and repairs in BlockSim, you must define the block as one that operates through system failure if you wish for backlog to be processed.  If this option is not set, the block will not operate through system failure and thus will not be able to process any backlog items when components that cause system failure (from an RBD perspective) fail.
 ==Variable Throughput==
-In many real-world cases throughput can change over time (i.e.,  throughput through a single component is not a constant but a function of time).  The discussion in this chapter is devoted to cases of constant, non-variable throughput.  BlockSim does model variable throughput using phase diagrams.  These are discussed in [[Reliability_Phase_Diagrams_(RPDs)|Introduction to Reliability Phase Diagrams]].
+In many real-world cases throughput can change over time (i.e.,  throughput through a single component is not a constant but a function of time). The discussion in this chapter is devoted to cases of constant, non-variable throughput. BlockSim does model variable throughput using phase diagrams.  These are discussed in [[Reliability_Phase_Diagrams_(RPDs)|Introduction to Reliability Phase Diagrams]].
 ==A Simple Throughput Analysis Example==

Richard House at 16:30, 21 September 2012

2012-09-21T16:30:58Z

Show changes

Kate Racaza: /* Throughput Analysis Options */

2012-08-22T01:56:25Z

Throughput Analysis Options

← Older revision		Revision as of 01:56, 22 August 2012
Line 90:		Line 90:
	It can be easily seen that the bottlenecks in the system are the blocks <math>F</math> and <math>G</math> .		It can be easily seen that the bottlenecks in the system are the blocks <math>F</math> and <math>G</math> .

	==Throughput Analysis Options==		==Throughput Analysis Options==<!-- THIS SECTION HEADER IS LINKED TO: Constant Throughput Example. IF YOU RENAME THE SECTION, YOU MUST UPDATE THE LINK. -->
	In BlockSim, specific throughput properties can be set for the blocks in the diagram.		In BlockSim, specific throughput properties can be set for the blocks in the diagram.

← Older revision		Revision as of 21:46, 22 December 2015
Line 97:		Line 97:
	'''Allocation''': Specify the allocation scheme across multiple paths (i.e., equal or weighted). This option is shown in the figure below.		'''Allocation''': Specify the allocation scheme across multiple paths (i.e., equal or weighted). This option is shown in the figure below.

	[[Image:throughput diagram.png\|center\|350px\|Throughput diagram.]]		[[Image:throughput diagram.png\|center\|350px\|Throughput diagram.\|link=]]

	To explain these settings, consider the example shown in the above figure, which uses the same notation as before.		To explain these settings, consider the example shown in the above figure, which uses the same notation as before.
Line 110:		Line 110:

	<center>''' Throughput summary using weighted allocation across paths.'''</center>		<center>''' Throughput summary using weighted allocation across paths.'''</center>
	[[Image:weighted allocation summary.png\|center\|550px\|]]		[[Image:weighted allocation summary.png\|center\|550px\|link=]]

	If the '''Allocate equal share to all paths''' option is chosen, then 20 units will be sent to <math>B\,\!</math>, <math>C\,\!</math> and <math>D\,\!</math> regardless of their processing capacity, yielding the results shown in the table below.		If the '''Allocate equal share to all paths''' option is chosen, then 20 units will be sent to <math>B\,\!</math>, <math>C\,\!</math> and <math>D\,\!</math> regardless of their processing capacity, yielding the results shown in the table below.

	<center>''' Throughput summary using an equal allocation across paths.'''</center>		<center>''' Throughput summary using an equal allocation across paths.'''</center>
	[[Image:equal allocation summary.png\|center\|550px\|]]		[[Image:equal allocation summary.png\|center\|550px\|link=]]

	'''Send units to failed blocks''': Decide whether items should be sent to failed parts.		'''Send units to failed blocks''': Decide whether items should be sent to failed parts.
Line 122:		Line 122:
	In the special case in which one or more blocks fail, causing a disruption in the path, and the '''Send units to failed blocks''' option is not selected, then the blocks that have a path to the failed block(s) will not be able to process any items, given the fact that they cannot be sent to the forward block. In this case, these blocks will keep all items received in their backlog. As an example, and using the figure below, if <math>E\,\!</math> is failed (and <math>E\,\!</math> cannot accept items in its backlog while failed), then <math>B\,\!</math>, <math>C\,\!</math> and <math>D\,\!</math> cannot forward any items to it. Thus, they will not process any items sent to them from <math>A\,\!</math>. Items sent from <math>A\,\!</math> will be placed in the backlogs of items <math>B\,\!</math>, <math>C\,\!</math> and <math>D.\,\!</math>		In the special case in which one or more blocks fail, causing a disruption in the path, and the '''Send units to failed blocks''' option is not selected, then the blocks that have a path to the failed block(s) will not be able to process any items, given the fact that they cannot be sent to the forward block. In this case, these blocks will keep all items received in their backlog. As an example, and using the figure below, if <math>E\,\!</math> is failed (and <math>E\,\!</math> cannot accept items in its backlog while failed), then <math>B\,\!</math>, <math>C\,\!</math> and <math>D\,\!</math> cannot forward any items to it. Thus, they will not process any items sent to them from <math>A\,\!</math>. Items sent from <math>A\,\!</math> will be placed in the backlogs of items <math>B\,\!</math>, <math>C\,\!</math> and <math>D.\,\!</math>

	[[Image:special backlog.png\|center\|350px\| Illustrating the special backlog case.]]		[[Image:special backlog.png\|center\|350px\| Illustrating the special backlog case.\|link=]]

	'''Process/Ignore backlog''': Identify how a block handles backlog. A block can ignore or process backlog. Items that cannot be processed are kept in a backlog bin and are processed as needed.		'''Process/Ignore backlog''': Identify how a block handles backlog. A block can ignore or process backlog. Items that cannot be processed are kept in a backlog bin and are processed as needed.
Line 129:		Line 129:

	<center>''' Scenario 3 summary with ''F'' and ''G'' having a limited blacklog and after one time unit.'''</center>		<center>''' Scenario 3 summary with ''F'' and ''G'' having a limited blacklog and after one time unit.'''</center>
	[[Image:limited backlog summary 1.png\|center\|550px\|]]		[[Image:limited backlog summary 1.png\|center\|550px\|link=]]

	<center>''' Scenario 3 summary with ''F'' and ''G'' having a limited backlog and after two time units.'''</center>		<center>''' Scenario 3 summary with ''F'' and ''G'' having a limited backlog and after two time units.'''</center>
	[[Image:limited backlog summary 2.png\|center\|550px\|]]		[[Image:limited backlog summary 2.png\|center\|550px\|link=]]

	Note that the blocks will never be able to process the backlog in this example. However, if we were to observe the system for a longer operation time and through failures and repairs of the other blocks, there would be opportunities for the blocks to process their backlogs and catch up. It is very important to note that when simulating a system with failures and repairs in BlockSim, you must define the block as one that operates through system failure if you wish for backlog to be processed. If this option is not set, the block will not operate through system failure and thus will not be able to process any backlog items when components that cause system failure (from an RBD perspective) fail.		Note that the blocks will never be able to process the backlog in this example. However, if we were to observe the system for a longer operation time and through failures and repairs of the other blocks, there would be opportunities for the blocks to process their backlogs and catch up. It is very important to note that when simulating a system with failures and repairs in BlockSim, you must define the block as one that operates through system failure if you wish for backlog to be processed. If this option is not set, the block will not operate through system failure and thus will not be able to process any backlog items when components that cause system failure (from an RBD perspective) fail.