Additional Analyses

Throughput Analysis

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 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]\displaystyle{ (100\cdot 10) }[/math] .

Throughput Metrics and Terminology

In looking at throughput, one needs to define some terminology and metrics that will describe the behavior of the system and its components when doing such analyses. Some of the terminology used in BlockSim is given next.

• System Throughput: System throughput is the total amount of items processed/produced by the system over the defined period of time. In the two-component example, this is [math]\displaystyle{ 1000 }[/math] items over [math]\displaystyle{ 100 }[/math] time units.

• Component Throughput: The total amount of items processed or produced by each component (block). In the two-component example, this is [math]\displaystyle{ 1000 }[/math] items each.

• Component Maximum Capacity: The maximum number of items that the component (block) could have processed/produced. This is simply the block's throughput rate multiplied by the run time. In the two-component example, this is [math]\displaystyle{ 100\cdot 10=1000 }[/math] for the first component and [math]\displaystyle{ 100\cdot 20=2000 }[/math] for the second component.

• Component Uptime Capacity: The maximum number of items the component could have processed/produced while it was up and running. In the two-component example, this is [math]\displaystyle{ 1000 }[/math] for the first component and [math]\displaystyle{ 2000 }[/math] for the second component, since we are assuming that the components cannot fail. If the components could fail, this number would be the component's uptime multiplied by its throughput rate.

• Component Excess Capacity: The additional amount a component could have processed/produced while up and running. In the two-component example, this is [math]\displaystyle{ 0 }[/math] for the first component and [math]\displaystyle{ 1000 }[/math] for the second component.

• Component Actual Utilization: The ratio of the component throughput and the component maximum capacity. In the two-component example, this is [math]\displaystyle{ 100% }[/math] for the first component and [math]\displaystyle{ 50% }[/math] for the second component.

• Component Uptime Utilization: The ratio of the component throughput and the component uptime capacity. In the two-component example, this is [math]\displaystyle{ 100% }[/math] for the first component and [math]\displaystyle{ 50% }[/math] for the second component. Note that if the components had failed and experienced downtime, this number would be different for each component.

• Backlog: Items that the component could not process are kept in a backlog. Depending on the settings, a backlog may or may not be processed when an opportunity arises. The available backlog metrics include:

o Component Backlog: The amount of a backlog present at the component at the end of the run (simulation).

o Component Processed Backlog: The amount of backlog processed by the component.

o Excess Backlog: Under specific settings in BlockSim, components can accept only a limited backlog. In these cases, a backlog that was rejected is stored in the Excess Backlog category.

Overview of Throughput Analysis

To examine throughput, consider the following scenarios.

Scenario 1

Throughput RBD for Scenario 1.

Consider the system shown in Figure Scenario1. Blocks [math]\displaystyle{ A }[/math] through [math]\displaystyle{ I }[/math] produce a number of items per unit time as identified next to each letter (e.g. [math]\displaystyle{ A }[/math]  : 100 implies [math]\displaystyle{ 100 }[/math] items per time unit for [math]\displaystyle{ 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.
This then implies that the following occurs over a single time unit:

• Unit [math]\displaystyle{ A }[/math] makes 100 items and routes 33.33 to [math]\displaystyle{ B }[/math] , 33.33 to [math]\displaystyle{ C }[/math] and 33.33 to [math]\displaystyle{ D }[/math] .

• In turn, [math]\displaystyle{ B }[/math] , [math]\displaystyle{ C }[/math] and [math]\displaystyle{ D }[/math] route their 33.33 to [math]\displaystyle{ E }[/math] , [math]\displaystyle{ F }[/math] , [math]\displaystyle{ G }[/math] and [math]\displaystyle{ H }[/math] (8.33 to each path).

• [math]\displaystyle{ E }[/math] , [math]\displaystyle{ F }[/math] , [math]\displaystyle{ G }[/math] and [math]\displaystyle{ H }[/math] route 25 each to [math]\displaystyle{ I }[/math] .

• [math]\displaystyle{ I }[/math] processes all 100.

• The system produces 100 items.

Thus, the following table would represent the throughput and excess capacity of each block after one time unit.

Table 1: Run summary for Scenario 1.

Scenario 2

Now consider Figure scenario2 where it is assumed that block [math]\displaystyle{ E }[/math] has failed.

Throughput RBD for Scenario 2.

Then:

• Unit [math]\displaystyle{ A }[/math] makes 100 items and routes 33.33 to [math]\displaystyle{ B }[/math] , 33.33 to [math]\displaystyle{ C }[/math] and 33.33 to [math]\displaystyle{ D }[/math] .

• In turn, [math]\displaystyle{ B }[/math] , [math]\displaystyle{ C }[/math] and [math]\displaystyle{ D }[/math] route their 33.33 to [math]\displaystyle{ F }[/math] , [math]\displaystyle{ G }[/math] and [math]\displaystyle{ H }[/math] (11.11 to each path that has an operating block at the end).

• [math]\displaystyle{ F }[/math] , [math]\displaystyle{ G }[/math] and [math]\displaystyle{ H }[/math] route 33.33 each to [math]\displaystyle{ I }[/math] .

• [math]\displaystyle{ I }[/math] processes all 100.

• The system produces 100 items.

A summary result table is shown next:

Table 2: Run summary for Scenario 2.

Scenario 3

Consider Figure scenario3 where both [math]\displaystyle{ E }[/math] and [math]\displaystyle{ H }[/math] have failed.

Throughput RBD for Scenario 3.

Then:

• Unit [math]\displaystyle{ A }[/math] makes 100 items and routes 33.33 to [math]\displaystyle{ B }[/math] , 33.33 to [math]\displaystyle{ C }[/math] and 33.33 to [math]\displaystyle{ D }[/math] .

• In turn, [math]\displaystyle{ B }[/math] , [math]\displaystyle{ C }[/math] and [math]\displaystyle{ D }[/math] route their 33.33 to [math]\displaystyle{ F }[/math] and [math]\displaystyle{ G }[/math] (16.66 to each path that has an operating block at the end).

• [math]\displaystyle{ F }[/math] and [math]\displaystyle{ G }[/math] get 50 items each.

• [math]\displaystyle{ F }[/math] and [math]\displaystyle{ G }[/math] process and route 40 each (their maximum processing capacity) to [math]\displaystyle{ I }[/math] . Both have a backlog of 10 since they could not process all 50 items they received.

• [math]\displaystyle{ I }[/math] processes all 80.

• The system produces 80 items.

Table 3: Run summary for Scenario 3.

Table 4: Utilization summary for Scenario 3.

It can be easily seen that the bottlenecks in the system are the blocks [math]\displaystyle{ F }[/math] and [math]\displaystyle{ G }[/math] .

BlockSim's throughput settings at the block level.

Throughput Analysis Options

Block Settings

In BlockSim, specific throughput properties can be set, as shown in Figure fig4 and outlined next.

Throughput per unit time: The number of items that the block can process per unit time.

Backlog Settings: 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.
Additionally, you can set the maximum number of items that can be stored in the backlog. When you choose to ignore the backlog, BlockSim will still report items that cannot be processed in the backlog column. However, it will let the backlog accumulate and never process it. In the case of a limited backlog, BlockSim will not accumulate more backlog than the maximum allowed and will discard all items sent to the block if they exceed its backlog capacity. It will keep count of the units that did not make it in the backlog in a category called Excess Backlog. To illustrate this, reconsider Scenario 3, but with both [math]\displaystyle{ F }[/math] and [math]\displaystyle{ G }[/math] having a limited backlog of 5. After a single time unit of operation, the results would be as shown in Tables 5 and 6.

Table 5: Scenario 3 summary with F and G having a limited blacklog and after one time unit

Table 6: Scenario 3 summary with F and G having a limited backlog and after two time units.

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.

[[Image:9.5.gif|thumb|center|400px|BlockSim's throughput settings for the entirre analysis (simulation).

Simulation Settings

Before running a throughput simulation, you can also specify the allocation scheme across multiple paths (i.e. equal or weighted) and decide whether items should be sent to failed parts. These options are shown in Figure fig5.

To explain these settings, consider the example shown in Figure ch8figsys, which uses the same notation as before.

Throughput diagram.

If the Weighted allocation across paths option is chosen, then the 60 items made by [math]\displaystyle{ A }[/math] will be allocated to [math]\displaystyle{ B }[/math] , [math]\displaystyle{ C }[/math] and [math]\displaystyle{ D }[/math] based on their throughput capabilities. Specifically, the portion that each block will receive, [math]\displaystyle{ {{P}_{i}} }[/math] , is:

[math]\displaystyle{ {{P}_{i}}=\frac{Throughpu{{t}_{i}}}{\underset{j=1}{\overset{N}{\mathop{\sum }}}\,Throughpu{{t}_{j}}} }[/math]

The actual amount is then the (portion [math]\displaystyle{ \cdot }[/math] available units). In this case, the portion allocated to [math]\displaystyle{ B }[/math] is [math]\displaystyle{ \tfrac{10}{60}, }[/math] the portion allocated to [math]\displaystyle{ C }[/math] is [math]\displaystyle{ \tfrac{20}{60} }[/math] and the portion allocated to [math]\displaystyle{ D }[/math] is [math]\displaystyle{ \tfrac{30}{60} }[/math] . When a total of 60 units is processed through [math]\displaystyle{ A }[/math] , [math]\displaystyle{ B }[/math] will get 10, [math]\displaystyle{ C }[/math] will get 20 and [math]\displaystyle{ D }[/math] will get 30.

The results would then be as shown in Table 7. If the Allocate equal share to all paths option is chosen, then 20 units will be sent to [math]\displaystyle{ B }[/math] , [math]\displaystyle{ C }[/math] and [math]\displaystyle{ D }[/math] regardless of their processing capacity, yielding the results shown in Table 8.

Table 7: throughput summary using weighted allocation across paths.

Table 8: Throughput summary using an equal allocation across paths.

Send units to failed blocks is the last option for BlockSim's throughput simulations. If this option is not selected, the throughput units are allocated only to operational units. Otherwise, if this option is selected, units are also allocated to failed blocks and they become part of the failed block's backlog.

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 Figure fig6, if [math]\displaystyle{ E }[/math] is failed (and [math]\displaystyle{ E }[/math] cannot accept items in its backlog while failed), then [math]\displaystyle{ B }[/math] , [math]\displaystyle{ C }[/math] and [math]\displaystyle{ D }[/math] cannot forward any items to it. Thus, they will not process any items sent to them from [math]\displaystyle{ A }[/math] . Items sent from [math]\displaystyle{ A }[/math] will be placed in the backlogs of items [math]\displaystyle{ B }[/math] , [math]\displaystyle{ C }[/math] and [math]\displaystyle{ D. }[/math]

Illustrating the special backlog case.

Variable Throughput

In many real-world cases throughput can change over time ( [math]\displaystyle{ i.e. }[/math] 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 Chapter 11.

Performing Throughput Analysis

The prior sections illustrated the basics concepts in throughput analysis. However, they did not take into account the reliability and maintenance properties of the blocks and the system. In a complete analysis, these would also need to be incorporated. The following simple example incorporates failures and repairs.

A Simple Throughput Analysis Example

To illustrate failures and repairs and their effects on system throughput, consider the simple system shown in Figure fig6a, but with [math]\displaystyle{ E }[/math] operating.

The system diagram for the example in Section 9.1.

In addition, consider the following deterministic failure and repair characteristics:

Also:

• Set all units to operate through system failure.

• Do not add spare part pools or crews (use defaults).

• Do not send items to failed units.

• Use a weighted allocation scheme.

Then the system behavior from 0 to 100 time units is given in Figure figsimple1. The system event history is as follows:

Once the system history has been established, we can examine the throughput behavior of this system from 0 to 100 by observing the sequence of events and their subsequent effect on system throughput.

The system behavior for the example in Section 9.1.

Event 1: [math]\displaystyle{ B }[/math] Fails at 50

Event overview:

• At 50, [math]\displaystyle{ B }[/math] fails.

• From 0 to 50, [math]\displaystyle{ A }[/math] processes [math]\displaystyle{ 50\cdot 60=3000 }[/math] items.

• 500 are sent to [math]\displaystyle{ B }[/math] , 1000 to [math]\displaystyle{ C }[/math] and 1500 to [math]\displaystyle{ D }[/math] . There is no excess capacity at [math]\displaystyle{ B }[/math] , [math]\displaystyle{ C }[/math] or [math]\displaystyle{ D }[/math] .

• [math]\displaystyle{ B }[/math] , [math]\displaystyle{ C }[/math] and [math]\displaystyle{ D }[/math] process and send 3000 items to [math]\displaystyle{ E }[/math] . Because the capacity of [math]\displaystyle{ E }[/math] is 3500, [math]\displaystyle{ E }[/math] now has an excess capacity of 500.

• The next table summarizes these results:

Event 2: [math]\displaystyle{ B }[/math] is Down 50 to 54

Event overview:

• From 50 to 54, [math]\displaystyle{ B }[/math] is down.

• [math]\displaystyle{ A }[/math] processes 240 items and sends 96 to [math]\displaystyle{ C }[/math] and 144 to [math]\displaystyle{ D }[/math] .

• [math]\displaystyle{ D }[/math] and [math]\displaystyle{ C }[/math] can only process 80 and 120 respectively during this time. Thus, they get backlogs of 16 and 24 respectively.

• The 200 processed are sent to [math]\displaystyle{ E }[/math] . [math]\displaystyle{ E }[/math] has an excess capacity of 80 during this time period.

• The next table summarizes these results:

Event 3: All Up 54 to 55

The next table summarizes the results:

Event 4: [math]\displaystyle{ C }[/math] is Down 55 to 59

The next table summarizes the results:

Event 5: All Up 59 to 60

The next table summarizes the results:

Event 6: [math]\displaystyle{ D }[/math] is Down 60 to 64

The next table summarizes the results:

Event 7: All Up 64 to 65

The next table summarizes the results:

Event 8: [math]\displaystyle{ A }[/math] is Down 65 to 69

Between 65 and 69, [math]\displaystyle{ A }[/math] fails. This stops the flow of items in the system and provides an opportunity for the other blocks to process their backlogs. As an example, [math]\displaystyle{ B }[/math] processes 40 items from the 60 items in its backlog. Specifically:

Event 9: All Up 69 to 70

The next table summarizes the results:

Event 10: [math]\displaystyle{ E }[/math] is Down 60 to 64

From 70 to 74, [math]\displaystyle{ E }[/math] is down. Because we specified that we will not send items to failed units, [math]\displaystyle{ B }[/math] , [math]\displaystyle{ C }[/math] and [math]\displaystyle{ D }[/math] receive items from [math]\displaystyle{ A }[/math] but they do not process them, since processing would require that items be sent to [math]\displaystyle{ E }[/math] . The items received by [math]\displaystyle{ B }[/math] , [math]\displaystyle{ C }[/math] and [math]\displaystyle{ D }[/math] are added to their respective backlogs. Furthermore, since they could have processed them if [math]\displaystyle{ E }[/math] had been up, all three blocks have an excess capacity for this period. Specifically:

It should be noted that if we had allowed items to be sent to failed blocks, [math]\displaystyle{ B }[/math] , [math]\displaystyle{ C }[/math] and [math]\displaystyle{ D }[/math] would have processed the items received and the backlog would have been at [math]\displaystyle{ E }[/math] . The rest of the time, all units are up.

Event 11: All Up 74 to 100

The next table summarizes the results:

Exploring the Results

Figure 9.10: System throughput summary.

BlockSim provides all of these results via the Simulation Results Explorer. Figure results1 shows the system throughput summary.

System level results present the total system throughput, which is 5484 items in this example. Additionally, the results include the uptime utilization of each component. The block level result summary, shown in Figure results2, provides additional results for each item. Finally, specific throughput results and metrics for each block are provided, as shown in Figures results3 and results4.

More Complex Scenarios

The examples presented here, even though trivial, form the basis of throughput analysis in BlockSim. The principles remain the same no matter how complex the system.

Figure 9.11: Block level summary.

Figure 9.12: Specific results per block.

Figure 9.13: Specific results per block.

Life Cycle Cost Analysis

A life cycle cost analysis involves the analysis of the costs of a system or a component over its entire life span. Typical costs for a system may include:

• Acquisition costs (or design and development costs).

• Operating costs:

o Cost of failures.

o Cost of repairs.

o Cost for spares.

o Downtime costs.

o Loss of production.

• Disposal costs.

A complete life cycle cost (LCC) analysis may also include other costs, as well as other accounting/financial elements (such as discount rates, interest rates, depreciation, present value of money, etc.).

For the purpose of this reference, it is sufficient to say that if one has all the required cost values (inputs), then a complete LCC analysis can be performed easily in a spreadsheet, since it really involves summations of costs and perhaps some computations involving interest rates. With respect to the cost inputs for such an analysis, the costs involved are either deterministic (such as acquisition costs, disposal costs, etc.) or probabilistic (such as cost of failures, repairs, spares, downtime, etc.). Most of the probabilistic costs are directly related to the reliability and maintainability characteristics of the system.

The estimations of the associated probabilistic costs is the challenging aspect of LCC analysis. In this section, we will look at using some of the cost inputs associated with BlockSim to obtain such costs using the following example.

Figure 9.14: Manufacturing line diagram.

Figure 9.15: Properties for blocks in manufacturing line.

Figure 9.16: Pool properties for maintenance on blocks in the manufacturing line.

Figure 9.17: Crew properties for maintenance on blocks in the manufacturing line.

Figure 9.18: The system in BlockSim.

Figure 9.19: Simulation settings in BlockSim.

Figure 9.20: System overview from BlockSim.

Figure 9.21: System costs summary from BlockSim.

Obtaining Costs for an LCC Analysis

Consider the manufacturing line (or system) shown in Figure LCCdiagram. The block properties are given in Figure LCCBlock, pool properties in Figure LCCpool and crew properties in Figure LCCCrew. All blocks identified with the same letter have the same properties (i.e. [math]\displaystyle{ A=A1=A2 }[/math] , [math]\displaystyle{ B=B1=B2=B3=B4 }[/math] and [math]\displaystyle{ C=C1=C2=C3=C4 }[/math] ). Figure LCCScreen shows this system in BlockSim.

This system was analyzed in BlockSim for a period of operation of 8,760 hours, or one year. The simulation settings are shown in Figure LCCsimsettings.

The system overview is shown in Figure figsysoverview. Most of the variable costs of interest were obtained directly from BlockSim. Figure figcostsummary shows the overall system costs.

[math]\displaystyle{ }[/math]

[math]\displaystyle{ }[/math]

Our total costs from the summary are $121,338. Note that an additional cost was defined in the problem statement that is not included in the summary. This cost, the operating cost per item per hour of operation, can be obtained by looking at the uptime of each block and then multiplying this by the cost per hour. This is given next.

If we also assume a revenue of $100 per unit produced, then the total revenue is our throughput multiplied by the per unit revenue, or [math]\displaystyle{ 31,651\cdot \$100=\$3,165,100. }[/math] The total costs are [math]\displaystyle{ 121,388+313,254=\$434,642. }[/math]