Implementing the Optimization

As was mentioned in the Improving Reliability section of this on-line reference, there are two different methods of implementing the changes suggested by the reliability optimization routine: fault tolerance and fault avoidance. Once the optimized component reliabilities have been determined, it does not matter which of the two methods is employed to realize the optimum reliability for the component in question. For example, suppose we have determined that a component must have its reliability for a certain mission time raised from 50% to 75%. The engineer must now decide how to go about implementing the increase in reliability. If the engineer decides to do this via fault avoidance, another component must be found (or the existing component must be redesigned) so that it will perform the same function with a higher reliability. On the other hand, if the engineer decides to go the fault tolerance route, the optimized reliability can be achieved merely by placing a second identical component in parallel with the first one.

Obviously, the method of implementing the reliability optimization is going to be related to the cost function and this is something the reliability engineer must take into account when deciding on what type of cost function is used for the optimization. In fact, if we take a closer look at the fault tolerance scheme, we can see some parallels with the general behavior cost model included in BlockSim. For example, consider a system that consists of a single unit. The cost of that unit, including all associated mounting and hardware costs, is one dollar. The reliability of this unit for a given mission time is 30%. It has been determined that this is inadequate and that a second component is to be added in parallel to increase the reliability. Thus, the reliability for the two-unit parallel system is:

So, the reliability has increased by a value of 21% and the cost has increased by one dollar. In a similar fashion, we can continue to add additional units in parallel, thus increasing the reliability and the cost. We now have an array of reliability values and the associated costs that we can use to develop a cost function for this fault tolerance scheme. Figure 6.15 shows the relationship between cost and reliability for this example.

Figure 6.15: Cost function for redundant parallel units.

As can be seen, this looks quite similar to the general behavior cost model discussed earlier. In fact, a standard regression analysis available in Weibull++ indicates that an exponential model fits this cost model quite well. (Note: For more information on performing a regression analysis using Weibull++, refer to the Non-Linear Equation Fit Solver chapter in the Weibull++ 7 User's Guide.) The function is given by the following equation, where C is the cost in dollars and R is the fractional reliability value.

Reliability Importance and Optimized Reliability Allocation (Analytical) Example 2

Consider a system consisting of three components connected reliability-wise in series. Assume the objective reliability for the system is 90% for a mission time of 100 hours. Five cases will be considered for the allocation problem. See Mettas [21].

In all cases, the maximum achievable reliability, Ri,max, for each component is 99.9% for a mission duration of 100 hours.

Solution to Reliability Importance and Optimized Reliability Allocation (Analytical) Example 2

Figure 6.16: Optimization inputs in BlockSim's Analytical QCP for Example 2, Case 1.

Case 1 - The reliability equation for Case 1 is:

Thus, the equality desired is:

(9)

Where:

The cost or feasibility function is:

(10)

Where:

And where (arbitrarily set), computed from the reliability function of each component at the time of interest, t = 100, or:

And f obtained from:

The solution, , is the one that satisfies Eqn. (9) while minimizing Eqn. (10). In this case (and since all the components are identical), the target reliability is found to be:

Figures 6.16 and 6.17 show related BlockSim screens. Based on this, each component's reliability should be at least 96.55% at 100 hours in order for the system's reliability to be 90% at 100 hours. Note the column labeled N.E.P.U. in the Results Panel shown in Figure 6.17. This stands for "Number of Equivalent Parallel Units" and represents the number of redundant units that would be required to bring that particular component up to the recommended reliability. In the case where the fault tolerance approach is to be implemented, the N.E.P.U value should be rounded up to an integer. Therefore, some manipulation by the engineer is required in order to ensure that the chosen integer values will yield the required system reliability goal (or exceed it). In addition, further cost analysis should be performed in order to account for the costs of adding redundancy to the system.

Figure 6.17: Optimization results for Example 2, Case 1.

Additionally, and once the results have been obtained, the engineer may wish to re-scale the components based on their distribution parameters instead of the fixed reliability value. In the case of these components, one may wish to re-scale the scale parameter of the distribution, η, for the components, or:

Which yields:

The Parameter Experimenter in BlockSim can also be used for this (Figure 6.18).

Figure 6.18: BlockSim's Parameter Experimenter used to determine a new based on the newly determined reliability targets.

The results from the other cases can be obtained in a similar fashion. The results for Cases 1 through 5 are summarized next.

Case 2 - It can be seen that the highest reliability was allocated to Component 1 with the Easy feasibility. The lowest reliability was assigned to Component 3 with the Hard feasibility. This makes sense in that an optimized reliability scheme will call for the greatest reliability changes in those components that are the easiest to change.

Case 3 - The components were different but had the same feasibility values. In other words, all three components have the same opportunity for improvement. This case differs from Cases 1 and 2 since there are two factors, not present previously, that will affect the outcome of the allocation in this case. First, each component in this case has a different reliability importance (impact of a component on the system's reliability); whereas in Cases 1 and 2, all three components were identical and had the same reliability importance.

Figure 6.19 shows the reliability importance for each component, where it can be seen that Component 1 has the greatest reliability importance and Component 3 has the smallest (this reliability importance also applies in Cases 4 and 5). This indicates that the reliability of Component 1 should be significantly increased because it has the biggest impact on the overall system reliability.

Figure 6.19: Reliability importance for Example 2, Case 3, 4 and 5.

In addition, each component's cost function in Case 3 also depends on the difference between each component's initial reliability and its corresponding maximum achievable reliability. (In Cases 1 and 2 this was not an issue because the components were identical.) The greater this difference, the greater the cost of improving the reliability of a particular component relative to the other two components. This difference between the initial reliability of a component and its maximum achievable reliability is called the range of improvement for that component. Since all three components have the same maximum achievable reliability, Component 1, with the largest range for improvement, is the most cost efficient component to improve. The improvement ranges for all three components are illustrated in Figure 6.20. At the same time, however, there is a reliability value between the initial and the maximum achievable reliability beyond which it becomes cost prohibitive to improve any further. This reliability value is dictated by the feasibility value. From the table of results, it can be seen that in Case 3 there was a 25.52% improvement for Component 1, 16.49% for Component 2 and 7.65% for Component 3.

Figure 6.20: Range of improvement for each component for Cases 3, 4 and 5.

Case 4 - As opposed to Case 3, Component 1 was assigned an even greater increase of 27.9%, with Components 2 and 3 receiving lesser increases than in Case 3, of 15.53% and 6.24% respectively. This is due to the fact that Component 1 has an Easy feasibility and Component 3 has a Hard feasibility, which means that it is more difficult to increase the reliability of Component 3 than to increase the reliability of Component 1.

Case 5 - The feasibility values here are reversed with Component 1 having a Hard feasibility and Component 3 an Easy feasibility. The recommended increase in Component 1's reliability is less compared to its increase for Cases 3 and 4. Note, however, that Components 2 and 3 still received a smaller increase in reliability than Component 1 because their ranges of improvement are smaller. In other words, Component 3 was assigned the smallest increase in reliability in Cases 3, 4 and 5 because its initial reliability is very close to its maximum achievable reliability.

Setting Specifications

The method of implementing the reliability optimization could also be used to arrive at initial specifications for a set of components. In the prior examples in this chapter of the on-line reference, we assumed a current reliability for the components. One could repeat these steps by choosing an arbitrary (lower) initial reliability for each component, thus allowing the algorithm to "travel up" to the target. When doing this, it is important to keep in mind the fact that both the distance from the target (the distance from the initial arbitrary value and the target value) for each component is also a significant contributor to the final results, as discussed in the prior example. If one wishes to arrive at the results using only the cost functions then it may be advantageous to set equal initial reliabilities for all components.

Other Notes on User-Defined Cost Functions

The optimization method in BlockSim is a very powerful tool for allocating reliability to the components of a system while minimizing an overall cost of improvement. The default cost function in BlockSim was derived in order to model a general relationship between the cost and the component reliability. However, if actual cost information is available, then one can use the cost data instead of using the default function. Additionally, one can also view the feasibility in the default function as a measure of the difficulty in increasing the reliability of the component relative to the rest of the components to be optimized, assuming that they also follow the same cost function with the corresponding feasibility values. If fault tolerance is a viable option, a reliability cost function for adding parallel units can be developed as demonstrated previously.

Another method for developing a reliability cost function would be to obtain different samples of components from different suppliers and testing the samples to determine the reliability of each sample type. From this data, a curve could be fitted through standard regression techniques and an equation defining the cost as a function of reliability could be developed. Figure 6.21 shows such a curve.

Lastly, and in cases where a reliability growth program is in place, the simplest way of obtaining a relationship between cost and reliability is by associating a cost to each development stage of the growth process. Reliability growth models such as the Crow (AMSAA), Duane, Gompertz and Logistic models can be used to describe the cost as a function of reliability.

Figure 6.21: Typical reliability growth curve generated using ReliaSoft

Figure 6.21: Typical reliability growth curve generated using ReliaSoft's Reliability Growth software.

If a reliability growth model has been successfully implemented, the development costs over the respective development time stages can be applied to the growth model, resulting in equations that describe reliability/cost relationships. These equations can then be entered into BlockSim as user-defined cost functions (feasibility policies). The only potential drawback to using growth model data is the lack of flexibility in applying the optimum results. Making the cost projection for future stages of the project would require the assumption that development costs will be accrued at a similar rate in the future, which may not always be a valid assumption. Also, if the optimization result suggests using a high reliability value for a component, it may take more time than is allotted for that project to attain the required reliability given the current reliability growth of the project.

See Also:
Reliability Importance and Optimized Reliability Allocation (Analytical)


Go to weibull.com
Go to ReliaSoft.com

©1999-2007. ReliaSoft Corporation. ALL RIGHTS RESERVED.