ReliaWiki - User contributions [en]

File:SCT with delay system.png

2012-09-06T15:48:07Z

Nikki Helms: uploaded a new version of "File:SCT with delay system.png"

File:Reliability-Community-Masthead-COLOR.png

2012-09-05T22:39:45Z

Nikki Helms: uploaded a new version of "File:Reliability-Community-Masthead-COLOR.png"

File:Reliability-Community-Masthead-COLOR.png

2012-09-05T18:39:55Z

Nikki Helms:

File:Reliability-Community-Masthead-Avant Garde font-color.png

2012-09-05T17:57:40Z

Nikki Helms:

File:Reliability-Community-Masthead-Avant Garde font3.png

2012-09-05T17:57:24Z

Nikki Helms:

File:Reliability-Community-Masthead-Avant Garde font2.png

2012-09-05T17:56:07Z

Nikki Helms:

File:Reliability-Community-Masthead-Avant Garde font.png

2012-09-05T17:55:40Z

Nikki Helms:

File:Reliability-Community-Masthead-4 noBGtest2.png

2012-09-05T00:03:03Z

Nikki Helms:

File:Reliability-Community-Masthead-4.png

2012-09-05T00:02:03Z

Nikki Helms: uploaded a new version of "File:Reliability-Community-Masthead-4.png": Reverted to version as of 23:50, 4 September 2012

File:Reliability-Community-Masthead-4.png

2012-09-05T00:01:10Z

Nikki Helms: uploaded a new version of "File:Reliability-Community-Masthead-4.png"

File:Reliability-Community-Masthead-4.png

2012-09-04T23:50:33Z

Nikki Helms: uploaded a new version of "File:Reliability-Community-Masthead-4.png"

File:Reliability-Community-Masthead-4.png

2012-09-04T23:09:43Z

Nikki Helms:

File:R38.png

2012-04-03T22:02:02Z

Nikki Helms: uploaded a new version of "File:R38.png"

Template:Example: Normal Distribution Likelihood Ratio Bound (Parameters)

2012-04-03T17:21:23Z

Nikki Helms:

'''Normal Distribution Likelihood Ratio Bound Example (Parameters)'''

Five units are put on a reliability test and experience failures at 12, 24, 28, 34, and 46 hours. Assuming a normal distribution, the MLE parameter estimates are calculated to be <math>\widehat{\mu }=28.8</math> and <math>\widehat{\sigma }=11.2143.</math> Calculate the two-sided 80% confidence bounds on these parameters using the likelihood ratio method.

'''Solution'''

The first step is to calculate the likelihood function for the parameter estimates:

::<math>\begin{align}
L(\widehat{\mu },\widehat{\sigma })= & \underset{i=1}{\overset{N}{\mathop \prod }}\,f({{t}_{i}};\widehat{\mu },\widehat{\sigma })=\underset{i=1}{\overset{5}{\mathop \prod }}\,\frac{1}{\widehat{\sigma }\cdot \sqrt{2\pi }}\cdot {{e}^{-\tfrac{1}{2}{{\left( \tfrac{{{t}_{i}}-\widehat{\mu }}{\widehat{\sigma }} \right)}^{2}}}} \\
L(\widehat{\mu },\widehat{\sigma })= & \underset{i=1}{\overset{5}{\mathop \prod }}\,\frac{1}{11.2143\cdot \sqrt{2\pi }}\cdot {{e}^{-\tfrac{1}{2}{{\left( \tfrac{{{t}_{i}}-28.8}{11.2143} \right)}^{2}}}} \\
L(\widehat{\mu },\widehat{\sigma })= & 4.676897\times {{10}^{-9}}
\end{align}</math>

where <math>{{t}_{i}}</math> are the original time-to-failure data points. We can now rearrange the likelihood ratio equation to the form:

::<math>L(\mu ,\sigma )-L(\widehat{\mu },\widehat{\sigma })\cdot {{e}^{\tfrac{-\chi _{\alpha ;1}^{2}}{2}}}=0</math>

Since our specified confidence level, <math>\delta </math> , is 80%, we can calculate the value of the chi-squared statistic, <math>\chi _{0.8;1}^{2}=1.642374.</math> We can now substitute this information into the equation:

::<math>\begin{align}
L(\mu ,\sigma )-L(\widehat{\mu },\widehat{\sigma })\cdot {{e}^{\tfrac{-\chi _{\alpha ;1}^{2}}{2}}}= & 0, \\
\\
L(\mu ,\sigma )-4.676897\times {{10}^{-9}}\cdot {{e}^{\tfrac{-1.642374}{2}}}= & 0, \\
\\
L(\mu ,\sigma )-2.057410\times {{10}^{-9}}= & 0.
\end{align}</math>

It now remains to find the values of <math>\mu </math> and <math>\sigma </math> which satisfy this equation. This is an iterative process that requires setting the value of <math>\mu </math> and finding the appropriate values of <math>\sigma </math> , and vice versa.

The following table gives the values of <math>\sigma </math> based on given values of <math>\mu </math> .

[[Image:tableofmu.png|center|500px| ]]

<math></math>
[[Image:WB.9 normal parameter contour plot.png|center|400px| ]]

<center><math>\begin{matrix}
\text{ }\!\!\mu\!\!\text{ } & {{\text{ }\!\!\sigma\!\!\text{ }}_{\text{1}}} & {{\text{ }\!\!\sigma\!\!\text{ }}_{\text{2}}} & \text{ }\!\!\mu\!\!\text{ } & {{\text{ }\!\!\sigma\!\!\text{ }}_{\text{1}}} & {{\text{ }\!\!\sigma\!\!\text{ }}_{\text{2}}} \\
\text{22}\text{.0} & \text{12}\text{.045} & \text{14}\text{.354} & \text{29}\text{.0} & \text{7.849}& \text{19.909} \\
\text{22}\text{.5} & \text{11}\text{.004} & \text{15}\text{.310} & \text{29}\text{.5} & \text{7}\text{.876} & \text{17}\text{.889} \\
\text{23}\text{.0} & \text{10}\text{.341} & \text{15}\text{.894} & \text{30}\text{.0} & \text{7}\text{.935} & \text{17}\text{.844} \\
\text{23}\text{.5} & \text{9}\text{.832} & \text{16}\text{.328} & \text{30}\text{.5} & \text{8}\text{.025} & \text{17}\text{.776} \\
\text{24}\text{.0} & \text{9}\text{.418} & \text{16}\text{.673} & \text{31}\text{.0} & \text{8}\text{.147} & \text{17}\text{.683} \\
\text{24}\text{.5} & \text{9}\text{.074} & \text{16}\text{.954} & \text{31}\text{.5} & \text{8}\text{.304} & \text{17}\text{.562} \\
\text{25}\text{.0} & \text{8}\text{.784} & \text{17}\text{.186} & \text{32}\text{.0} & \text{8}\text{.498} & \text{17}\text{.411} \\
\text{25}\text{.5} & \text{8}\text{.542} & \text{17}\text{.377} & \text{32}\text{.5} & \text{8}\text{.732} & \text{17}\text{.227} \\
\text{26}\text{.0} & \text{8}\text{.340} & \text{17}\text{.534} & \text{33}\text{.0} & \text{9}\text{.012} & \text{17}\text{.004} \\
\text{26}\text{.5} & \text{8}\text{.176} & \text{17}\text{.661} & \text{33}\text{.5} & \text{9}\text{.344} & \text{16}\text{.734} \\
\text{27}\text{.0} & \text{8}\text{.047} & \text{17}\text{.760} & \text{34}\text{.0} & \text{9}\text{.742} & \text{16}\text{.403} \\
\text{27}\text{.5} & \text{7}\text{.950} & \text{17}\text{.833} & \text{34}\text{.5} & \text{10}\text{.229} & \text{15}\text{.990} \\
\text{28}\text{.0} & \text{7}\text{.885} & \text{17}\text{.882} & \text{35}\text{.0} & \text{10}\text{.854} & \text{15}\text{.444} \\
\text{28}\text{.5} & \text{7}\text{.852} & \text{17}\text{.907} & \text{35}\text{.5} & \text{11}\text{.772} & \text{14}\text{.609} \\
\end{matrix}</math></center>

This data set is represented graphically in the following contour plot:

(Note that this plot is generated with degrees of freedom <math>k=1</math> , as we are only determining bounds on one parameter. The contour plots generated in Weibull++ are done with degrees of freedom <math>k=2</math> , for use in comparing both parameters simultaneously.) As can be determined from the table, the lowest calculated value for <math>\sigma </math> is 7.849, while the highest is 17.909. These represent the two-sided 80% confidence limits on this parameter. Since solutions for the equation do not exist for values of <math>\mu </math> below 22 or above 35.5, these can be considered the two-sided 80% confidence limits for this parameter. In order to obtain more accurate values for the confidence limits on <math>\mu </math> , we can perform the same procedure as before, but finding the two values of <math>\mu </math> that correspond with a given value of <math>\sigma .</math> Using this method, we find that the two-sided 80% confidence limits on <math>\mu </math> are 21.807 and 35.793, which are close to the initial estimates of 22 and 35.5.

Template:Example: Normal Distribution Likelihood Ratio Bound (Time)

2012-04-03T17:20:52Z

Nikki Helms:

'''Normal Distribution Likelihood Ratio Bound Example (Time)'''

For the data given in Example 5, determine the two-sided 80% confidence bounds on the time estimate for a reliability of 40%. The ML estimate for the time at <math>R(t)=40%</math> is 31.637.

'''Solution'''

In this example, we are trying to determine the two-sided 80% confidence bounds on the time estimate of 31.637. This is accomplished by substituting <math>R=0.40</math> and <math>\alpha =0.8</math> into the likelihood ratio equation for the normal distribution, and varying <math>\sigma </math> until the maximum and minimum values of <math>t</math> are found. The following table gives the values of <math>t</math> based on given values of <math>\sigma </math> .

[[Image:tabletbasedonsigma.png|center|500px| ]]
<math></math>

This data set is represented graphically in the following contour plot:

[[Image:WB.9 time v sigma contour.png|center|400px| ]]

As can be determined from the table, the lowest calculated value for <math>t</math> is 25.046, while the highest is 39.250. These represent the 80% confidence limits on the time at which reliability is equal to 40%.

File:Tablerbasedonsigma.png

2012-04-03T17:19:43Z

Nikki Helms:

Template:Example: Normal Distribution Likelihood Ratio Bound (Reliability)

2012-04-03T17:19:28Z

Nikki Helms:

'''Normal Distribution Likelihood Ratio Bound Example (Reliability)'''

For the data given in Example 5, determine the two-sided 80% confidence bounds on the reliability estimate for <math>t=30</math> . The ML estimate for the reliability at <math>t=30</math> is 45.739%.

'''Solution'''
In this example, we are trying to determine the two-sided 80% confidence bounds on the reliability estimate of 45.739%. This is accomplished by substituting <math>t=30</math> and <math>\alpha =0.8</math> into the likelihood ratio equation for normal distribution, and varying <math>\sigma </math> until the maximum and minimum values of <math>R</math> are found. The following table gives the values of <math>R</math> based on given values of <math>\sigma </math> .

[[Image:tablerbasedonsigma.png|center|500px| ]]

This data set is represented graphically in the following contour plot:

[[Image:WB.9 reliability v sigma.png|center|400px| ]]

As can be determined from the table, the lowest calculated value for <math>R</math> is 24.776%, while the highest is 68.000%. These represent the 80% two-sided confidence limits on the reliability at <math>t=30</math>

File:Tabletbasedonsigma.png

2012-04-03T16:26:54Z

Nikki Helms:

Template:Example: Normal Distribution Likelihood Ratio Bound (Time)

2012-04-03T16:26:11Z

Nikki Helms:

'''Normal Distribution Likelihood Ratio Bound Example (Time)'''

For the data given in Example 5, determine the two-sided 80% confidence bounds on the time estimate for a reliability of 40%. The ML estimate for the time at <math>R(t)=40%</math> is 31.637.

'''Solution'''

In this example, we are trying to determine the two-sided 80% confidence bounds on the time estimate of 31.637. This is accomplished by substituting <math>R=0.40</math> and <math>\alpha =0.8</math> into the likelihood ratio equation for the normal distribution, and varying <math>\sigma </math> until the maximum and minimum values of <math>t</math> are found. The following table gives the values of <math>t</math> based on given values of <math>\sigma </math> .

[[Image:tabletbasedonsigma.png|center|400px| ]]
<math></math>

This data set is represented graphically in the following contour plot:

[[Image:WB.9 time v sigma contour.png|center|400px| ]]

As can be determined from the table, the lowest calculated value for <math>t</math> is 25.046, while the highest is 39.250. These represent the 80% confidence limits on the time at which reliability is equal to 40%.

File:Tableofmu.png

2012-04-02T21:57:43Z

Nikki Helms:

Template:Example: Normal Distribution Likelihood Ratio Bound (Parameters)

2012-04-02T21:57:12Z

Nikki Helms:

'''Normal Distribution Likelihood Ratio Bound Example (Parameters)'''

Five units are put on a reliability test and experience failures at 12, 24, 28, 34, and 46 hours. Assuming a normal distribution, the MLE parameter estimates are calculated to be <math>\widehat{\mu }=28.8</math> and <math>\widehat{\sigma }=11.2143.</math> Calculate the two-sided 80% confidence bounds on these parameters using the likelihood ratio method.

'''Solution'''

The first step is to calculate the likelihood function for the parameter estimates:

::<math>\begin{align}
L(\widehat{\mu },\widehat{\sigma })= & \underset{i=1}{\overset{N}{\mathop \prod }}\,f({{t}_{i}};\widehat{\mu },\widehat{\sigma })=\underset{i=1}{\overset{5}{\mathop \prod }}\,\frac{1}{\widehat{\sigma }\cdot \sqrt{2\pi }}\cdot {{e}^{-\tfrac{1}{2}{{\left( \tfrac{{{t}_{i}}-\widehat{\mu }}{\widehat{\sigma }} \right)}^{2}}}} \\
L(\widehat{\mu },\widehat{\sigma })= & \underset{i=1}{\overset{5}{\mathop \prod }}\,\frac{1}{11.2143\cdot \sqrt{2\pi }}\cdot {{e}^{-\tfrac{1}{2}{{\left( \tfrac{{{t}_{i}}-28.8}{11.2143} \right)}^{2}}}} \\
L(\widehat{\mu },\widehat{\sigma })= & 4.676897\times {{10}^{-9}}
\end{align}</math>

where <math>{{t}_{i}}</math> are the original time-to-failure data points. We can now rearrange the likelihood ratio equation to the form:

::<math>L(\mu ,\sigma )-L(\widehat{\mu },\widehat{\sigma })\cdot {{e}^{\tfrac{-\chi _{\alpha ;1}^{2}}{2}}}=0</math>

Since our specified confidence level, <math>\delta </math> , is 80%, we can calculate the value of the chi-squared statistic, <math>\chi _{0.8;1}^{2}=1.642374.</math> We can now substitute this information into the equation:

::<math>\begin{align}
L(\mu ,\sigma )-L(\widehat{\mu },\widehat{\sigma })\cdot {{e}^{\tfrac{-\chi _{\alpha ;1}^{2}}{2}}}= & 0, \\
\\
L(\mu ,\sigma )-4.676897\times {{10}^{-9}}\cdot {{e}^{\tfrac{-1.642374}{2}}}= & 0, \\
\\
L(\mu ,\sigma )-2.057410\times {{10}^{-9}}= & 0.
\end{align}</math>

It now remains to find the values of <math>\mu </math> and <math>\sigma </math> which satisfy this equation. This is an iterative process that requires setting the value of <math>\mu </math> and finding the appropriate values of <math>\sigma </math> , and vice versa.

The following table gives the values of <math>\sigma </math> based on given values of <math>\mu </math> .

[[Image:tableofmu.png|center|400px| ]]

<math></math>
[[Image:WB.9 normal parameter contour plot.png|center|400px| ]]

<center><math>\begin{matrix}
\text{ }\!\!\mu\!\!\text{ } & {{\text{ }\!\!\sigma\!\!\text{ }}_{\text{1}}} & {{\text{ }\!\!\sigma\!\!\text{ }}_{\text{2}}} & \text{ }\!\!\mu\!\!\text{ } & {{\text{ }\!\!\sigma\!\!\text{ }}_{\text{1}}} & {{\text{ }\!\!\sigma\!\!\text{ }}_{\text{2}}} \\
\text{22}\text{.0} & \text{12}\text{.045} & \text{14}\text{.354} & \text{29}\text{.0} & \text{7.849}& \text{19.909} \\
\text{22}\text{.5} & \text{11}\text{.004} & \text{15}\text{.310} & \text{29}\text{.5} & \text{7}\text{.876} & \text{17}\text{.889} \\
\text{23}\text{.0} & \text{10}\text{.341} & \text{15}\text{.894} & \text{30}\text{.0} & \text{7}\text{.935} & \text{17}\text{.844} \\
\text{23}\text{.5} & \text{9}\text{.832} & \text{16}\text{.328} & \text{30}\text{.5} & \text{8}\text{.025} & \text{17}\text{.776} \\
\text{24}\text{.0} & \text{9}\text{.418} & \text{16}\text{.673} & \text{31}\text{.0} & \text{8}\text{.147} & \text{17}\text{.683} \\
\text{24}\text{.5} & \text{9}\text{.074} & \text{16}\text{.954} & \text{31}\text{.5} & \text{8}\text{.304} & \text{17}\text{.562} \\
\text{25}\text{.0} & \text{8}\text{.784} & \text{17}\text{.186} & \text{32}\text{.0} & \text{8}\text{.498} & \text{17}\text{.411} \\
\text{25}\text{.5} & \text{8}\text{.542} & \text{17}\text{.377} & \text{32}\text{.5} & \text{8}\text{.732} & \text{17}\text{.227} \\
\text{26}\text{.0} & \text{8}\text{.340} & \text{17}\text{.534} & \text{33}\text{.0} & \text{9}\text{.012} & \text{17}\text{.004} \\
\text{26}\text{.5} & \text{8}\text{.176} & \text{17}\text{.661} & \text{33}\text{.5} & \text{9}\text{.344} & \text{16}\text{.734} \\
\text{27}\text{.0} & \text{8}\text{.047} & \text{17}\text{.760} & \text{34}\text{.0} & \text{9}\text{.742} & \text{16}\text{.403} \\
\text{27}\text{.5} & \text{7}\text{.950} & \text{17}\text{.833} & \text{34}\text{.5} & \text{10}\text{.229} & \text{15}\text{.990} \\
\text{28}\text{.0} & \text{7}\text{.885} & \text{17}\text{.882} & \text{35}\text{.0} & \text{10}\text{.854} & \text{15}\text{.444} \\
\text{28}\text{.5} & \text{7}\text{.852} & \text{17}\text{.907} & \text{35}\text{.5} & \text{11}\text{.772} & \text{14}\text{.609} \\
\end{matrix}</math></center>

This data set is represented graphically in the following contour plot:

(Note that this plot is generated with degrees of freedom <math>k=1</math> , as we are only determining bounds on one parameter. The contour plots generated in Weibull++ are done with degrees of freedom <math>k=2</math> , for use in comparing both parameters simultaneously.) As can be determined from the table, the lowest calculated value for <math>\sigma </math> is 7.849, while the highest is 17.909. These represent the two-sided 80% confidence limits on this parameter. Since solutions for the equation do not exist for values of <math>\mu </math> below 22 or above 35.5, these can be considered the two-sided 80% confidence limits for this parameter. In order to obtain more accurate values for the confidence limits on <math>\mu </math> , we can perform the same procedure as before, but finding the two values of <math>\mu </math> that correspond with a given value of <math>\sigma .</math> Using this method, we find that the two-sided 80% confidence limits on <math>\mu </math> are 21.807 and 35.793, which are close to the initial estimates of 22 and 35.5.

File:Confidencechart3.png

2012-04-02T19:06:01Z

Nikki Helms:

Template:Example: Likelihood Ratio Bounds on Reliability (Type 2)

2012-04-02T19:05:48Z

Nikki Helms:

'''Likelihood Ratio Bounds on Reliability (Type 2)'''

For the data given in Example 1, determine the 90% two-sided confidence bounds on the reliability estimate for <math>t=45</math>. The ML estimate for the reliability at <math>t=45</math> is 14.816%.

'''Solution'''

In this example, we are trying to determine the 90% two-sided confidence bounds on the reliability estimate of 14.816%. As was mentioned, we need to rewrite the likelihood ratio equation so that it is in terms of <math>R</math> and <math>\beta .</math> This is again accomplished by substituting the Weibull reliability equation into the <math>\eta </math> term in the likelihood ratio equation to form a likelihood equation in terms of <math>R</math> and <math>\beta </math>:

::<math>\begin{align}
& L(\beta ,R)= & \underset{i=1}{\overset{N}{\mathop \prod }}\,f({{x}_{i}};\beta ,t,R) \\
& &
\end{align}</math>

::<math>=\underset{i=1}{\overset{5}{\mathop \prod }}\,\frac{\beta }{\left( \tfrac{t}{{{(-\text{ln}(R))}^{\tfrac{1}{\beta }}}} \right)}\cdot {{\left( \frac{{{x}_{i}}}{\left( \tfrac{t}{{{(-\text{ln}(R))}^{\tfrac{1}{\beta }}}} \right)} \right)}^{\beta -1}}\cdot \text{exp}\left[ -{{\left( \frac{{{x}_{i}}}{\left( \tfrac{t}{{{(-\text{ln}(R))}^{\tfrac{1}{\beta }}}} \right)} \right)}^{\beta }} \right]</math>

where <math>{{x}_{i}}</math> are the original time-to-failure data points. We can now rearrange the likelihood ratio equation to the form:

::<math>L(\beta ,R)-L(\widehat{\beta },\widehat{\eta })\cdot {{e}^{\tfrac{-\chi _{\alpha ;1}^{2}}{2}}}=0</math>

Since our specified confidence level, <math>\delta </math>, is 90%, we can calculate the value of the chi-squared statistic, <math>\chi _{0.9;1}^{2}=2.705543.</math> We can now substitute this information into the equation:

::<math>\begin{align}
L(\beta ,R)-L(\widehat{\beta },\widehat{\eta })\cdot {{e}^{\tfrac{-\chi _{\alpha ;1}^{2}}{2}}}= & 0 \\
\\
L(\beta ,R)-1.714714\times {{10}^{-9}}\cdot {{e}^{\tfrac{-2.705543}{2}}}= & 0 \\
\\
L(\beta ,R)-4.432926\cdot {{10}^{-10}}= & 0
\end{align}</math>

It now remains to find the values of <math>\beta </math> and <math>R</math> that satisfy this equation. This is an iterative process that requires setting the value of <math>\beta </math> and finding the appropriate values of <math>R</math>. The following table gives the values of <math>R</math> based on given values of <math>\beta </math>.

[[Image:confidencechart3.png|center|400px|]]

These points are represented graphically in the following contour plot:

[[Image:weibull contour plot reliability beta.png|center|350px|]]

As can be determined from the table, the lowest calculated value for <math>R</math> is 2.38%, while the highest is 44.26%. These represent the 90% two-sided confidence limits on the reliability at <math>t=45</math>.

File:Confidencechart2.png

2012-04-02T18:55:39Z

Nikki Helms: uploaded a new version of "File:Confidencechart2.png"

File:Confidencechart2.png

2012-04-02T18:52:58Z

Nikki Helms:

Template:Example: Likelihood Ratio Bounds on Time (Type I)

2012-04-02T18:52:41Z

Nikki Helms:

'''Likelihood Ratio Bounds on Time (Type I)'''

For the data given in Example 1, determine the 90% two-sided confidence bounds on the time estimate for a reliability of 50%. The ML estimate for the time at which <math>R(t)=50%</math> is 28.930.

'''Solution'''

In this example, we are trying to determine the 90% two-sided confidence bounds on the time estimate of 28.930. As was mentioned, we need to rewrite the likelihood ratio equation so that it is in terms of <math>t</math> and <math>\beta .</math> This is accomplished by using a form of the Weibull reliability equation, <math>R={{e}^{-{{\left( \tfrac{t}{\eta } \right)}^{\beta }}}}.</math> This can be rearranged in terms of <math>\eta </math>, with <math>R</math> being considered a known variable or:

::<math>\eta =\frac{t}{{{(-\text{ln}(R))}^{\tfrac{1}{\beta }}}}</math>

This can then be substituted into the <math>\eta </math> term in the likelihood ratio equation to form a likelihood equation in terms of <math>t</math> and <math>\beta </math> or:

::<math>\begin{align}
& L(\beta ,t)= & \underset{i=1}{\overset{N}{\mathop \prod }}\,f({{x}_{i}};\beta ,t,R) \\
& &
\end{align}</math>

::<math>=\underset{i=1}{\overset{5}{\mathop \prod }}\,\frac{\beta }{\left( \tfrac{t}{{{(-\text{ln}(R))}^{\tfrac{1}{\beta }}}} \right)}\cdot {{\left( \frac{{{x}_{i}}}{\left( \tfrac{t}{{{(-\text{ln}(R))}^{\tfrac{1}{\beta }}}} \right)} \right)}^{\beta -1}}\cdot \text{exp}\left[ -{{\left( \frac{{{x}_{i}}}{\left( \tfrac{t}{{{(-\text{ln}(R))}^{\tfrac{1}{\beta }}}} \right)} \right)}^{\beta }} \right]</math>

where <math>{{x}_{i}}</math> are the original time-to-failure data points. We can now rearrange the likelihood ratio equation to the form:

::<math>L(\beta ,t)-L(\widehat{\beta },\widehat{\eta })\cdot {{e}^{\tfrac{-\chi _{\alpha ;1}^{2}}{2}}}=0</math>

Since our specified confidence level, <math>\delta </math>, is 90%, we can calculate the value of the chi-squared statistic, <math>\chi _{0.9;1}^{2}=2.705543.</math> We can now substitute this information into the equation:

::<math>\begin{align}
L(\beta ,t)-L(\widehat{\beta },\widehat{\eta })\cdot {{e}^{\tfrac{-\chi _{\alpha ;1}^{2}}{2}}}= & 0 \\
\\
L(\beta ,t)-1.714714\times {{10}^{-9}}\cdot {{e}^{\tfrac{-2.705543}{2}}}= & 0 \\
& \\
L(\beta ,t)-4.432926\cdot {{10}^{-10}}= & 0
\end{align}</math>

Note that the likelihood value for <math>L(\widehat{\beta },\widehat{\eta })</math> is the same as it was for Example 1. This is because we are dealing with the same data and parameter estimates or, in other words, the maximum value of the likelihood function did not change. It now remains to find the values of <math>\beta </math> and <math>t</math> which satisfy this equation. This is an iterative process that requires setting the value of <math>\beta </math> and finding the appropriate values of <math>t</math>. The following table gives the values of <math>t</math> based on given values of <math>\beta </math>.

[[Image:confidencechart2.png|center|400px|]]

These points are represented graphically in the following contour plot:

[[Image:weibull contour plot time beta.png|center|400px|]]

As can be determined from the table, the lowest calculated value for <math>t</math> is 17.389, while the highest is 41.714. These represent the 90% two-sided confidence limits on the time at which reliability is equal to 50%.

File:Confidencechart1.png

2012-04-02T18:29:09Z

Nikki Helms:

Template:Example: Likelihood Ratio Bounds on Parameters

2012-04-02T18:28:33Z

Nikki Helms:

'''Likelihood Ratio Bounds on Parameters'''

Five units were put on a reliability test and experienced failures at 10, 20, 30, 40 and 50 hours. Assuming a Weibull distribution, the MLE parameter estimates are calculated to be <math>\widehat{\beta }=2.2938</math> and <math>\widehat{\eta }=33.9428.</math> Calculate the 90% two-sided confidence bounds on these parameters using the likelihood ratio method.

 '''Solution'''

The first step is to calculate the likelihood function for the parameter estimates:

::<math>\begin{align}
L(\widehat{\beta },\widehat{\eta })= & \underset{i=1}{\overset{N}{\mathop \prod }}\,f({{x}_{i}};\widehat{\beta },\widehat{\eta })=\underset{i=1}{\overset{5}{\mathop \prod }}\,\frac{\widehat{\beta }}{\widehat{\eta }}\cdot {{\left( \frac{{{x}_{i}}}{\widehat{\eta }} \right)}^{\widehat{\beta }-1}}\cdot {{e}^{-{{\left( \tfrac{{{x}_{i}}}{\widehat{\eta }} \right)}^{\widehat{\beta }}}}} \\
\\
L(\widehat{\beta },\widehat{\eta })= & \underset{i=1}{\overset{5}{\mathop \prod }}\,\frac{2.2938}{33.9428}\cdot {{\left( \frac{{{x}_{i}}}{33.9428} \right)}^{1.2938}}\cdot {{e}^{-{{\left( \tfrac{{{x}_{i}}}{33.9428} \right)}^{2.2938}}}} \\
\\
L(\widehat{\beta },\widehat{\eta })= & 1.714714\times {{10}^{-9}}
\end{align}</math>

 where ''x''''i'' are the original time-to-failure data points. We can now rearrange the likelihood ratio equation to the form:

 

::<math>L(\beta ,\eta )-L(\widehat{\beta },\widehat{\eta })\cdot {{e}^{\tfrac{-\chi _{\alpha ;1}^{2}}{2}}}=0</math>

 Since our specified confidence level, δ, is 90%, we can calculate the value of the chi-squared statistic, <math>\chi _{0.9;1}^{2}=2.705543.</math> We then substitute this information into the equation:

::<math>\begin{align}
L(\beta ,\eta )-L(\widehat{\beta },\widehat{\eta })\cdot {{e}^{\tfrac{-\chi _{\alpha ;1}^{2}}{2}}}= & 0 \\
\\
L(\beta ,\eta )-1.714714\times {{10}^{-9}}\cdot {{e}^{\tfrac{-2.705543}{2}}}= & 0 \\
\\
L(\beta ,\eta )-4.432926\cdot {{10}^{-10}}= & 0
\end{align}</math>

 The next step is to find the set of values of β and η that satisfy this equation, or find the values of β and η such that <math>L(\beta ,\eta )=4.432926\cdot {{10}^{-10}}.</math>

The solution is an iterative process that requires setting the value of β and finding the appropriate values of η, and vice versa. The following table gives values of β based on given values of η.

 [[Image:Confidencechart1.png|center|300px]]

 These data are represented graphically in the following contour plot:

 [[Image:weibull parameter contour plot.png|center|350px]]

 (Note that this plot is generated with degrees of freedom ''k'' = 1, as we are only determining bounds on one parameter. The contour plots generated in Weibull++ are done with degrees of freedom ''k'' = 2, for use in comparing both parameters simultaneously.) As can be determined from the table, the lowest calculated value for β is 1.142, while the highest is 3.950. These represent the two-sided 90% confidence limits on this parameter. Since solutions for the equation do not exist for values of η below 23 or above 50, these can be considered the 90% confidence limits for this parameter. In order to obtain more accurate values for the confidence limits on η, we can perform the same procedure as before, but finding the two values of η that correspond with a given value of β. Using this method, we find that the 90% confidence limits on η are 22.474 and 49.967, which are close to the initial estimates of 23 and 50.

 Note that the points where β are maximized and minimized do not necessarily correspond with the points where η are maximized and minimized. This is due to the fact that the contour plot is not symmetrical, so that the parameters will have their extremes at different points.

Template:Voltage Step-Stress Example

2012-04-02T17:50:59Z

Nikki Helms: /* Voltage Step-Stress Example */

===Voltage Step-Stress Example===

An electronic component was subjected to a voltage stress, starting at 2V (use stress level) and increased to 7V in stepwise increments. The following steps, in hours, were used to apply stress to the products under test: 0 to 250, 2V; 250 to 350, 3V; 350 to 370, 4V; 370 to 380, 5V; 380 to 390, 6V; and 390 to 400, 7V. This profile is represented graphically next.
 
 
[[Image:ALTA14.20.png|center|500px|]]
 

The objective of this test was to determine the <math>B10</math> life of these components at the normal use stress level of 2V.
 
In this experiment, the overall test time was 385 hrs. If the test had been performed at use conditions, one would expect the test duration to be approximately 1700 hrs if the test were run until all units failed.
 
Eleven units were available for the test. All eleven units were tested using the same stress profile. Units that failed were removed from the test and their total time on test recorded. The following times-to-failure were observed in the test, in hours: 280, 310, 330, 352, 360, 366, 371, 374, 378, 381 and 385.

====Solution====

After creating a Standard Folio for a single stress (voltage), the analyst added a Stress Profile under Tools in the Project Manager to create the stress profile for this experiment. In ALTA's stress profile, you can define any stress profile in segments. The stress applied during these segments can be a constant value (as is the case in this step example) or defined as a function of a time variable (t). The stress profile for this analysis is displayed next.
 
 
[[Image:chp14-65.gif|thumb|center|400px|]]
 
[[Image:ALTA14.21.gif|thumb|center|400px|The voltage test profile as in ALTA.]]
 

The times-to-failure data are entered in the ALTA Standard Folio with the following analysis options selected: cumulative damage power life-stress relationship and Weibull for the underlying life distribution. The ALTA Standard Folio with the data entered and the estimated parameters is shown next. Notice that the voltage step-stress profile has been assigned to each data point.

 
[[Image:chp14-66.gif|thumb|center|400px|]]

The <math>B10</math> life at the 2V use stress level, can be calculated with ALTA's Quick Calculation Pad (QCP), as shown next.

[[Image:Ch12-Ex9-4.gif|thumb|center|400px|]]

File:ALTA14.20.png

2012-04-02T17:50:14Z

Nikki Helms:

Template:Voltage Step-Stress Example

2012-04-02T17:50:02Z

Nikki Helms: /* Voltage Step-Stress Example */

===Voltage Step-Stress Example===

An electronic component was subjected to a voltage stress, starting at 2V (use stress level) and increased to 7V in stepwise increments. The following steps, in hours, were used to apply stress to the products under test: 0 to 250, 2V; 250 to 350, 3V; 350 to 370, 4V; 370 to 380, 5V; 380 to 390, 6V; and 390 to 400, 7V. This profile is represented graphically next.
 
 
[[Image:ALTA14.20.png|center|300px|]]
 

The objective of this test was to determine the <math>B10</math> life of these components at the normal use stress level of 2V.
 
In this experiment, the overall test time was 385 hrs. If the test had been performed at use conditions, one would expect the test duration to be approximately 1700 hrs if the test were run until all units failed.
 
Eleven units were available for the test. All eleven units were tested using the same stress profile. Units that failed were removed from the test and their total time on test recorded. The following times-to-failure were observed in the test, in hours: 280, 310, 330, 352, 360, 366, 371, 374, 378, 381 and 385.

====Solution====

After creating a Standard Folio for a single stress (voltage), the analyst added a Stress Profile under Tools in the Project Manager to create the stress profile for this experiment. In ALTA's stress profile, you can define any stress profile in segments. The stress applied during these segments can be a constant value (as is the case in this step example) or defined as a function of a time variable (t). The stress profile for this analysis is displayed next.
 
 
[[Image:chp14-65.gif|thumb|center|400px|]]
 
[[Image:ALTA14.21.gif|thumb|center|400px|The voltage test profile as in ALTA.]]
 

The times-to-failure data are entered in the ALTA Standard Folio with the following analysis options selected: cumulative damage power life-stress relationship and Weibull for the underlying life distribution. The ALTA Standard Folio with the data entered and the estimated parameters is shown next. Notice that the voltage step-stress profile has been assigned to each data point.

 
[[Image:chp14-66.gif|thumb|center|400px|]]

The <math>B10</math> life at the 2V use stress level, can be calculated with ALTA's Quick Calculation Pad (QCP), as shown next.

[[Image:Ch12-Ex9-4.gif|thumb|center|400px|]]

File:11 2ex.png

2012-04-02T17:49:38Z

Nikki Helms:

Electronic Devices Example

2012-04-02T17:49:26Z

Nikki Helms: /* Electronic Devices Example */

===Electronic Devices Example===

 
Twelve electronic devices were put into a continuous accelerated test. The accelerated stresses were temperature and voltage, with use level conditions of 328K and 2V respectively. The data set obtained is shown in the table below:
 
 
[[Image:11_2ex.png|center|300px|]]
 
Do the following:

1) Using the T-NT Weibull model, analyze the data in ALTA and determine the MTTF and B(10) life for these devices at use level. Determine the upper and lower 90% 2-sided confidence intervals on the results.

2) Examine the effects of each stress on life.

====Solution====

1. The data set was analyzed in ALTA and the following MTTF and <math>B(10)</math> life results were obtained: (''The results are shown in ALTA's QCP in the following figures.'')

 
[[Image:pv_ex2_1.gif|thumb|center|300px|]]

 
[[Image:pv_ex2_2.gif|thumb|center|300px|]]
 
 

2. The next two figures examine the effects of each stress on life.

 
Specifically, the next figure shows the Life vs. Voltage plot with temperature held constant at 328K.

[[Image:ALTA14.6.gif|thumb|center|300px|The effects of voltage on life, with temperature held constant at 328K.]]

The next figure shows the Life vs. Temperature plot with voltage held constant at 2V.

 
[[Image:ALTA14.7.gif|thumb|center|300px|The effects of temperature on life, with voltage held constant at 2V.]]
 
 
The next figure shows a 3D plot of reliability (at a constant time) versus both stresses. One can observe that reliability declines slightly faster with the change in temperature than with the change in voltage. Note that in the following plot, Stress 1 refers to temperature and Stress 2 refers to voltage.

[[Image:ALTA14.8.gif|thumb|center|300px|The combined effects of voltage and temperature on the reliability, as plotted in ALTA.]]

File:Closeclip.png

2012-04-02T17:47:52Z

Nikki Helms:

File:Openclip.png

2012-04-02T17:47:21Z

Nikki Helms:

Template:Paper Clip Example

2012-04-02T17:47:04Z

Nikki Helms: /* Paper Clip Example */

===Paper Clip Example===

To illustrate the principles behind accelerated testing, consider the following simple example which involves a paper clip and can be easily and independently performed by the reader. The objective was to determine the mean number of cycles-to-failure of a given paper clip. The use cycles were assumed to be at a 45º bend. The acceleration stress was determined to be the angle to which we bend the clips, thus two accelerated bend stresses of 90º and 180º were used. The paper clips were tested using the following procedure for the 90º bend. A similar procedure was also used for the 180º and 45º test.

1) '''Open the Paper Clip.'''
 
[[Image:openclip.png|center|300px|]]
 
2) With one hand, hold the clip by the longer, outer loop.

3) With the thumb and forefinger of the other hand, grasp the smaller, inner loop.

4) Pull the smaller, inner loop out and down 90 degrees so that a right angle is formed as shown.

5) '''Close the Paper Clip.'''
 
[[Image:closeclip.png|center|300px|]]
 
6) With one hand, continue to hold the clip by the longer, outer loop.

7) With the thumb and forefinger of the other hand, grasp the smaller, inner loop.

8) Push the smaller inner loop up and in 90 degrees so that the smaller loop is returned to the original upright position in line with the larger, outer loop as shown.

9) This completes one cycle.

10) Repeat until the paper clip breaks. Count and record the cycles-to-failure for each clip.

At this point, the reader must note that the paper clips used in this example were Jumbo paper clips capable of repeated bending. Different paper clips will yield different results. Additionally, and so that no other stresses are imposed, caution must be taken to assure that the rate at which the paper clips are cycled remains the same across the experiment.

For the experiment, a sample of six paper clips was tested to failure at both 90º and 180º bends. A base test sample of six paper clips was tested at a 45º bend (the assumed use stress level) to confirm the analysis. The cycles-to-failure are given next.

<div style="text-align: center;"> '''Cycles-to-Failure at <math>90^\circ </math> [[File:90degree.gif]] </div>
 
<div style="text-align: center;"> 16, 17, 18, 21, 22, 23 cycles.</div>
 
<div style="text-align: center;"> '''Cycles-to-Failure at <math>180^\circ </math> [[File:180degree.gif]]</div>
 
<div style="text-align: center;"> 4, 4, 5, 6, 6, 8 cycles.</div>
 
<div style="text-align: center;"> '''Cycles-to-Failure at <math>45^\circ </math> [[File:45degree.gif]]</div>
 
<div style="text-align: center;"> 58, 63, 65, 72, 78, 86 cycles.</div>

 
The accelerated test data set was then analyzed in ALTA, assuming a lognormal life distribution (fatigue) and an inverse power law relationship (non-thermal) for the life-stress model. The analysis and some of the results are shown in the next figures.

[[Image:degreesbend.png|thumb|center|400px|The accelerated test data analyzed in ALTA.]]
 
 
[[Image:probweib.png|thumb|center|400px|Lognormal probabiliyt plot of both stress levels from ALTA.]]
 
 
[[Image:accvsstress.png|thumb|center|400px|The resulting Acceleration Factor vs. Stress plot from ALTA.]]

 
The MTTF at 45 degrees is found to be 71.375467 cycles as shown next.

 
[[Image:Ch12-Ex1-4.png|thumb|center|400px|The Mean Life at 45 degrees bend.]]

The next two figures show the analysis of the base data in Weibull++ and the base MTTF estimate. In this case, our accelerated test correctly predicted the MTTF as verified by our base test.

 
[[Image:ALTA14.5b.gif|thumb|center|300px|The base <math>45^\circ </math> data analyzed in ReliaSoft's Weibull++, utilizing a lognormal distribution shown on lognormal probability paper.]]

 
[[Image:ALTA14.5.gif|thumb|center|400px|Calculated Mean Life from base test.]]

File:11 8ex.png

2012-04-02T17:45:43Z

Nikki Helms:

Template:Electronic Components Example

2012-04-02T17:45:16Z

Nikki Helms: /* Electronic Components Example */

===Electronic Components Example===

An electronic component was redesigned and was tested to failure at three different temperatures. Six units were tested at each stress level. At the 406K stress level however, a unit was removed from the test due to a test equipment failure which led to a failure of the component. A warranty time of one year is to be given, with an expected return of 10% of the population. The times-to-failure and test temperatures are given next:

 
 
[[Image:11_8ex.png|center|300px|]]
 

The operating temperature is 356K. Using the Arrhenius-Weibull model, determine the following:

1) Should the first failure at 406K be included in the analysis?

2) Determine the warranty time for a 90% reliability.

3) Determine the 90% lower confidence limit on the warranty time.

4) Is the warranty requirement met? If not, what steps should be taken?

5) Repeat the analysis with the unrelated failure included. Is there any difference?

6) If the unrelated failure occurred at 500 hr, should it be included in the analysis?

====Solution====

1) Since the failure occurred at the very beginning of the test and for an unrelated reason, it can be omitted from the analysis. If it is included it should be treated as a suspension and not as a failure.

2) The first failure at 406K was neglected and the data were analyzed using ALTA. The following parameters were obtained:

::<math>\begin{align}

\beta =\ & 2.965820 \\

B=\ & 10679.567542 \\

C=\ & 2.396615\cdot {{10}^{-9}}

\end{align}</math>

The use level probability plot (at 356K) can then be obtained. The warranty time for a reliability of 90% (or an unreliability of 10%) can be estimated from this plot as shown next.

 
[[Image:issue.gif|thumb|center|300px| The probability plot at use stress level.]]

 
This estimate can also be obtained from the Arrhenius plot (a Life vs. Stress plot). The 10th percentile (time for a reliability of 90%) is plotted versus stress. This type of plot is useful because a time for a given reliability can be determined for different stress levels.

 
[[Image:example_1_life_vs_stress.gif|thumb|center|300px|10% unreliability vs stress.]]

 
A more accurate way to determine the warranty time would be to use ALTA's Quick Calculation Pad (QCP). By selecting the Reliable Life option from in the QCP and entering 356 for the temperature and 0.9 for the required reliability, a reliable life of 11,977.792719 hr can be determined, as shown next:

 
[[Image:ex1_qcp.gif|thumb|center|300px|]]

 
3) The warranty time for a 90% reliability was estimated to be approximately 12,000 hr. This is above the 1 year (8,760 hr) requirement. However, this is an estimate at the 50% confidence level. In other words, 50% of the time life will be greater than 12,000 hr and 50% of the time life will be less. A known confidence level is therefore crucial before any decisions are made. Using ALTA, confidence bounds can be plotted on both probability and Arrhenius plots. In the following use level probability plot, the 90% lower confidence level (LCL) is plotted. Note that percentile bounds are Type 1 confidence bounds in ALTA.

 
[[Image:example_1_use_prob_plot_with_cb.gif|thumb|center|300px|The use level probability plot with the Type I 90% lower bound.]]

 
An estimated 4,437 hr warranty time at a 90% lower confidence level was obtained from the use level probability plot. This means that 90% of the time, life will be greater than this value. In other words, a life of 4,437 hr is a bounding value for the warranty.

 
The Arrhenius plot with the 90% lower confidence level is shown next.

 
[[Image:example_1_life_vs_stress_with_cb.gif|thumb|center|300px|Life vs Stress plot with the 90% lower confidence level.]]

Using the QCP and specifying a 90% lower confidence level, a warranty time of 4436.5 hr is estimated, as shown next.
 
 
[[Image:ex1_qcp2.gif|thumb|center|300px|]]

 
4) The warranty time for this component is estimated to be 4,436.5 hr at a 90% lower confidence bound. This is much less than the 1 year warranty time required (almost 6 months). Thus the desired warranty is not met. In this case, the following four options are available:

:a) Redesign.

:b) Reduce the confidence level.

:c) Change the warranty policy.

:d) Test additional units at stress levels closer to the use level.

5) Including the unrelated failure of 0.3 hr at 406 K (by treating it as a suspension at that time), the following results are obtained:

::<math>\begin{align}

\beta =\ & 2.965804 \\

B=\ & 10679.566625 \\

C=\ & 2.396619\cdot {{10}^{-9}}

\end{align}</math>

These results are essentially identical to the ones with the unrelated failure excluded. A small difference can be seen only if more significant digits are considered. The warranty time with the 90% lower 1-sided confidence bound was estimated to be:

::<math>\begin{align}

T=\ & 11977.729145\text{ hr} \\

{{T}_{L}}=\ & 4436.462084\text{ hr}

\end{align}</math>

Again, the difference is negligible. This is due to the very early time at which this unrelated failure occurred.

6) The analysis is repeated treating the unrelated failure at 500 hr as a suspension, with the following results:

::<math>\begin{align}

\beta =\ & 3.022714 \\

B=\ & 10959.523204 \\

C=\ & 1.23808\cdot {{10}^{-9}}

\end{align}</math>

In this case, the results are very different. The warranty time with the 90% lower 1-sided confidence bound is estimated to be:

::<math>\begin{align}
T=\ & 13780.208409\text{ hr} \\
{{T}_{L}}=\ & 5303.672050\text{ hr}
\end{align}</math>

It can be seen that in this case, it would be a mistake to neglect the unrelated failure. By neglecting this failure, we would actually underestimate the warranty time. The important observation in this example is that every piece of life information is crucial. In other words, unrelated failures also provide information about the life of the product. An unrelated failure occurring at 500 hr indicates that the product has survived for that period of time under the particular stress level, thus neglecting it would be a mistake. On the other hand it would also be a mistake to treat this data point as a failure, since the failure was caused by a test equipment failure.

Template:Electronic Components Example

2012-04-02T17:31:39Z

Nikki Helms: /* Electronic Components Example */

===Electronic Components Example===

An electronic component was redesigned and was tested to failure at three different temperatures. Six units were tested at each stress level. At the 406K stress level however, a unit was removed from the test due to a test equipment failure which led to a failure of the component. A warranty time of one year is to be given, with an expected return of 10% of the population. The times-to-failure and test temperatures are given next:

 
 
[[Image:11_8ex.gif|center|300px|]]
 

The operating temperature is 356K. Using the Arrhenius-Weibull model, determine the following:

1) Should the first failure at 406K be included in the analysis?

2) Determine the warranty time for a 90% reliability.

3) Determine the 90% lower confidence limit on the warranty time.

4) Is the warranty requirement met? If not, what steps should be taken?

5) Repeat the analysis with the unrelated failure included. Is there any difference?

6) If the unrelated failure occurred at 500 hr, should it be included in the analysis?

====Solution====

1) Since the failure occurred at the very beginning of the test and for an unrelated reason, it can be omitted from the analysis. If it is included it should be treated as a suspension and not as a failure.

2) The first failure at 406K was neglected and the data were analyzed using ALTA. The following parameters were obtained:

::<math>\begin{align}

\beta =\ & 2.965820 \\

B=\ & 10679.567542 \\

C=\ & 2.396615\cdot {{10}^{-9}}

\end{align}</math>

The use level probability plot (at 356K) can then be obtained. The warranty time for a reliability of 90% (or an unreliability of 10%) can be estimated from this plot as shown next.

 
[[Image:issue.gif|thumb|center|300px| The probability plot at use stress level.]]

 
This estimate can also be obtained from the Arrhenius plot (a Life vs. Stress plot). The 10th percentile (time for a reliability of 90%) is plotted versus stress. This type of plot is useful because a time for a given reliability can be determined for different stress levels.

 
[[Image:example_1_life_vs_stress.gif|thumb|center|300px|10% unreliability vs stress.]]

 
A more accurate way to determine the warranty time would be to use ALTA's Quick Calculation Pad (QCP). By selecting the Reliable Life option from in the QCP and entering 356 for the temperature and 0.9 for the required reliability, a reliable life of 11,977.792719 hr can be determined, as shown next:

 
[[Image:ex1_qcp.gif|thumb|center|300px|]]

 
3) The warranty time for a 90% reliability was estimated to be approximately 12,000 hr. This is above the 1 year (8,760 hr) requirement. However, this is an estimate at the 50% confidence level. In other words, 50% of the time life will be greater than 12,000 hr and 50% of the time life will be less. A known confidence level is therefore crucial before any decisions are made. Using ALTA, confidence bounds can be plotted on both probability and Arrhenius plots. In the following use level probability plot, the 90% lower confidence level (LCL) is plotted. Note that percentile bounds are Type 1 confidence bounds in ALTA.

 
[[Image:example_1_use_prob_plot_with_cb.gif|thumb|center|300px|The use level probability plot with the Type I 90% lower bound.]]

 
An estimated 4,437 hr warranty time at a 90% lower confidence level was obtained from the use level probability plot. This means that 90% of the time, life will be greater than this value. In other words, a life of 4,437 hr is a bounding value for the warranty.

 
The Arrhenius plot with the 90% lower confidence level is shown next.

 
[[Image:example_1_life_vs_stress_with_cb.gif|thumb|center|300px|Life vs Stress plot with the 90% lower confidence level.]]

Using the QCP and specifying a 90% lower confidence level, a warranty time of 4436.5 hr is estimated, as shown next.
 
 
[[Image:ex1_qcp2.gif|thumb|center|300px|]]

 
4) The warranty time for this component is estimated to be 4,436.5 hr at a 90% lower confidence bound. This is much less than the 1 year warranty time required (almost 6 months). Thus the desired warranty is not met. In this case, the following four options are available:

:a) Redesign.

:b) Reduce the confidence level.

:c) Change the warranty policy.

:d) Test additional units at stress levels closer to the use level.

5) Including the unrelated failure of 0.3 hr at 406 K (by treating it as a suspension at that time), the following results are obtained:

::<math>\begin{align}

\beta =\ & 2.965804 \\

B=\ & 10679.566625 \\

C=\ & 2.396619\cdot {{10}^{-9}}

\end{align}</math>

These results are essentially identical to the ones with the unrelated failure excluded. A small difference can be seen only if more significant digits are considered. The warranty time with the 90% lower 1-sided confidence bound was estimated to be:

::<math>\begin{align}

T=\ & 11977.729145\text{ hr} \\

{{T}_{L}}=\ & 4436.462084\text{ hr}

\end{align}</math>

Again, the difference is negligible. This is due to the very early time at which this unrelated failure occurred.

6) The analysis is repeated treating the unrelated failure at 500 hr as a suspension, with the following results:

::<math>\begin{align}

\beta =\ & 3.022714 \\

B=\ & 10959.523204 \\

C=\ & 1.23808\cdot {{10}^{-9}}

\end{align}</math>

In this case, the results are very different. The warranty time with the 90% lower 1-sided confidence bound is estimated to be:

::<math>\begin{align}
T=\ & 13780.208409\text{ hr} \\
{{T}_{L}}=\ & 5303.672050\text{ hr}
\end{align}</math>

It can be seen that in this case, it would be a mistake to neglect the unrelated failure. By neglecting this failure, we would actually underestimate the warranty time. The important observation in this example is that every piece of life information is crucial. In other words, unrelated failures also provide information about the life of the product. An unrelated failure occurring at 500 hr indicates that the product has survived for that period of time under the particular stress level, thus neglecting it would be a mistake. On the other hand it would also be a mistake to treat this data point as a failure, since the failure was caused by a test equipment failure.

Template:Example:GLL

2012-03-30T21:55:06Z

Nikki Helms: /* GLL Example */

==GLL Example==
 
Consider the data summarized in the following tables. These data illustrate a typical three-stress type accelerated test.
 
 
<center>Stress Profile Summary</center>
[[Image:ALTA11t1.png|center|400px|]]
 

<center>Failure Data</center>
[[Image:ALTA11t2.png|center|500px|]]

 
The data in the second table are analyzed assuming a Weibull distribution, an Arrhenius life-stress relationship for temperature and an inverse power life-stress relationship for voltage. No transformation is performed on the operation type. The operation type variable is treated as an indicator variable, taking the discrete values of 0 and 1, for on/off and continuous operation, respectively. The following figure, shows the stress types and their transformations as in ALTA.
 
[[Image:StressTransformation.gif|thumb|center|300px|]]

 
The GLL relationship then becomes:

 
::<math>\eta ={{e}^{{{\alpha }_{0}}+{{\alpha }_{1}}\tfrac{1}{{{V}_{1}}}+{{\alpha }_{2}}\ln ({{V}_{2}})+{{\alpha }_{3}}{{V}_{3}}}}</math>

 
The resulting relationship after performing these transformations is:

 
::<math>\begin{align}
& \eta = & {{e}^{{{\alpha }_{0}}}}{{e}^{{{\alpha }_{1}}\tfrac{1}{{{V}_{1}}}}}{{e}^{{{\alpha }_{2}}\ln ({{V}_{2}})}}{{e}^{{{\alpha }_{3}}{{V}_{3}}}} =\ & {{e}^{{{\alpha }_{0}}}}{{e}^{{{\alpha }_{1}}\tfrac{1}{{{V}_{1}}}}}V_{2}^{{{\alpha }_{2}}}{{e}^{{{\alpha }_{3}}{{V}_{3}}}}
\end{align}</math>

 
Therefore, the parameter <math>B</math> of the Arrhenius relationship is equal to the log-linear coefficient <math>{{\alpha }_{1}}</math> , and the parameter <math>n</math> of the inverse power relationship is equal to ( <math>-{{\alpha }_{2}}</math> ). Therefore <math>\eta </math> can also be written as:

 
::<math>\eta ={{e}^{{{\alpha }_{0}}}}{{e}^{\tfrac{B}{{{V}_{1}}}}}V_{2}^{n}{{e}^{{{\alpha }_{3}}{{V}_{3}}}}</math>

 
The activation energy of the Arrhenius relationship can be calculated by multiplying B with Boltzmann's constant.
 
The best fit values for the parameters in this case are:

 
::<math>\begin{align}
\beta = & 3.7483;\text{ }{{\alpha }_{0}}=-6.0220;\text{ }{{\alpha }_{1}}=5776.9341 \\
{{\alpha }_{2}}= & -1.4340;\text{ }{{\alpha }_{3}}=0.6242.
\end{align}</math>

 
Once the parameters are estimated, further analysis on the data can be performed. First, using ALTA, a Weibull probability plot of the data can be obtained, as shown next.
 

 
[[Image:ALTA11.1.gif|thumb|center|300px|Weibull probability plot for all covariates.]]
 
 
Several types of information about the model as well as the data can be obtained from a probability plot. For example, the choice of an underlying distribution and the assumption of a common slope (shape parameter) can be examined. In this example, the linearity of the data supports the use of the Weibull distribution. In addition, the data appear parallel on this plot, therefore reinforcing the assumption of a common beta. Further statistical analysis can and should be performed for these purposes as well.
The Life vs. Stress plot is a very common plot for the analysis of accelerated data. Life vs. Stress plots can be very useful in assessing the effect of each stress on a product's failure. In this case, since the life is a function of three stresses, three different plots can be created. Such plots are created by holding two of the stresses constant at the desired use level, and varying the remaining one. The use stress levels for this example are 328K for temperature and 10V for voltage. For the operation type, a decision has to be made by the engineers as to whether they implement on/off or continuous operation. The next two figures display the effects of temperature and voltage on the life of the product.
 
[[Image:ALTA11.2.gif|thumb|center|300px|Effects of temperature on life.]]
 
 
[[Image:ALTA11.3.gif|thumb|center|300px|Effects of voltage on life.]]
 
 
The effects of the two different operation types on life can be observed in the next figure. It can be seen that the on/off cycling has a greater effect on the life of the product in terms of accelerating failure than the continuous operation. In other words, a higher reliability can be achieved by running the product continuously.

 
[[Image:ALTA11.4.gif|thumb|center|300px|Effect of operation type on life.]]

Template:Aaw frf

2012-03-30T21:37:49Z

Nikki Helms: /* Arrhenius-Weibull Failure Rate Function */

====Arrhenius-Weibull Failure Rate Function====
 
The Arrhenius-Weibull failure rate function, <math>\lambda (T)</math> , is given by:

 
::<math>\lambda \left( T,V \right)=\frac{f\left( T,V \right)}{R\left( T,V \right)}=\frac{\beta }{C\cdot {{e}^{\tfrac{B}{V}}}}{{\left( \frac{T}{C\cdot {{e}^{\tfrac{B}{V}}}} \right)}^{\beta -1}}</math>
 
[[Image:ALTA6.9.png|center|800px|Failure rate function for <math>\Beta<1 </math>, <math>\Beta=1 </math>, and <math>\Beta>1 </math>.]]

Template:Aaw rf

2012-03-30T21:37:04Z

Nikki Helms: /* Arrhenius-Weibull Reliability Function */

====Arrhenius-Weibull Reliability Function====
 
The Arrhenius-Weibull reliability function is given by:

 
::<math>R(T,V)={{e}^{-{{\left( \tfrac{T}{C\cdot {{e}^{\tfrac{B}{V}}}} \right)}^{\beta }}}}</math>

 
If the parameter <math>B</math> is positive, then the reliability increases as stress decreases.
 
[[Image:ALTA6.7.png|center|400px|Behavior of the reliability function at different stress and constant parameter values.]]
 

 
The behavior of the reliability function of the Weibull distribution for different values of <math>\beta </math> was illustrated [[Distributions used in Accelerated Testing#The Weibull Distribution|here]]. In the case of the Arrhenius-Weibull model, however, the reliability is a function of stress also. A 3D plot such as the ones shown in the next figure is now needed to illustrate the effects of both the stress and <math>\beta .</math>

 
::<math></math>

 
[[Image:ALTA6.8.png|center|800px|Reliability function for <math>\Beta<1 </math>, <math>\Beta=1 </math>, and <math>\Beta>1 </math>.]]

Template:Lognormal distribution characteristics

2012-03-30T21:26:55Z

Nikki Helms: /* Characteristics of Lognormal Distribution */

==Characteristics of Lognormal Distribution ==
[[Image:WB.10 effect of sigma.png|center|400px| ]]
<math></math>

:• The lognormal distribution is a distribution skewed to the right.
:• The <math>pdf</math> starts at zero, increases to its mode, and decreases thereafter.
:• The degree of skewness increases as <math>{{\sigma'}}</math> increases, for a given <math>\mu'</math>

[[Image:WB.10 lognormal pdf.png|center|400px| ]]

:• For the same <math>{{\sigma'}}</math> , the <math>pdf</math> 's skewness increases as <math>{\mu }'</math> increases.
:• For <math>{{\sigma' }}</math> values significantly greater than 1, the <math>pdf</math> rises very sharply in the beginning, i.e. for very small values of <math>T</math> near zero, and essentially follows the ordinate axis, peaks out early, and then decreases sharply like an exponential <math>pdf</math> or a Weibull <math>pdf</math> with <math>0<\beta <1</math> .
:• The parameter, <math>{\mu }'</math>, in terms of the logarithm of the <math>{T}'s</math> is also the scale parameter, and not the location parameter as in the case of the normal <math>pdf</math> .
:• The parameter <math>{{\sigma'}}</math>, or the standard deviation of the <math>{T}'s</math> in terms of their logarithm or of their <math>{T}'</math>, is also the shape parameter and not the scale parameter, as in the normal <math>pdf</math>, and assumes only positive values.

'''Lognormal Distribution Parameters in Weibull++'''

In Weibull++, the parameters returned for the lognormal distribution are always logarithmic. That is: the parameter <math>{\mu }'</math> represents the mean of the natural logarithms of the times-to-failure, while <math>{{\sigma' }}</math> represents the standard deviation of these data point logarithms. Specifically, the returned <math>{{\sigma' }}</math> is the square root of the variance of the natural logarithms of the data points. Even though the application denotes these values as mean and standard deviation, the user is reminded that these are given as the parameters of the distribution, and are thus the mean and standard deviation of the natural logarithms of the data. The mean value of the times-to-failure, not used as a parameter, as well as the standard deviation can be obtained through the QCP or the Function Wizard.

File:BS7.7.png

2012-03-30T21:01:37Z

Nikki Helms: uploaded a new version of "File:BS7.7.png"

Introduction to Repairable Systems

2012-03-30T21:01:02Z

Nikki Helms: /* Discussion on Example 2 */

{{Template:bsbook|7}}

=Repairable Systems=

In prior chapters, the analysis was focused on determining the reliability of the system (i.e. the probability that the system, subsystem or component will operate successfully by a given time, <math>t</math> .) The prior formulations provided us with the probability of success of the entire system, up to a point in time, without looking at the question: ``What happens if a component fails during that time and is then fixed?'' In dealing with repairable systems, these definitions need to be redefined and adapted to deal with this case of the renewal of systems/components.
 

Repairable systems receive maintenance actions that restore/renew system components when they fail. These actions change the overall makeup of the system. These actions must now be taken into consideration when assessing the behavior of the system because the age of the system components is no longer uniform nor is the time of operation of the system continuous.
 

In attempting to understand the system behavior, additional information and models are now needed for each system component. Our primary input in the prior chapters was a model that described how the component failed (its failure probability distribution). When dealing with components that are repaired, one also needs to know how long it takes for the component to be restored. That is, at the very least, one needs a model that describes how the component is restored (a repair probability distribution).
 

In this chapter, we will introduce the additional information, models and metrics required to fully analyze a repairable system.

[[Category:Completed Theoretical Review]]

=Defining Maintenance=

To properly deal with repairable systems, we need to first understand how components in these systems are restored (i.e. the maintenance actions that the components undergo). In general, maintenance is defined as any action that restores failed units to an operational condition or retains non-failed units in an operational state. For repairable systems, maintenance plays a vital role in the life of a system. It affects the system's overall reliability, availability, downtime, cost of operation, etc. Generally, maintenance actions can be divided into three types: corrective maintenance, preventive maintenance and inspections.

===Corrective Maintenance===

Corrective maintenance consists of the action(s) taken to restore a failed system to operational status. This usually involves replacing or repairing the component that is responsible for the failure of the overall system. Corrective maintenance is performed at unpredictable intervals because a component's failure time is not known a priori. The objective of corrective maintenance is to restore the system to satisfactory operation within the shortest possible time. Corrective maintenance is typically carried out in three steps:
 

:• Diagnosis of the problem. The maintenance technician must take time to locate the failed parts or otherwise satisfactorily assess the cause of the system failure. 
:• Repair and/or replacement of faulty component(s). Once the cause of system failure has been determined, action must be taken to address the cause, usually by replacing or repairing the components that caused the system to fail. 
:• Verification of the repair action. Once the components in question have been repaired or replaced, the maintenance technician must verify that the system is again successfully operating. 
 

===Preventive Maintenance===

Preventive maintenance, unlike corrective maintenance, is the practice of replacing components or subsystems before they fail in order to promote continuous system operation. The schedule for preventive maintenance is based on observation of past system behavior, component wear-out mechanisms and knowledge of which components are vital to continued system operation. Cost is always a factor in the scheduling of preventive maintenance. In many circumstances, it is financially more sensible to replace parts or components that have not failed at predetermined intervals rather than to wait for a system failure that may result in a costly disruption in operations. Preventive maintenance scheduling strategies are discussed in more detail later in this chapter.

===Inspections===

Inspections are used in order to uncover hidden failures (also called dormant failures). In general, no maintenance action is performed on the component during an inspection unless the component is found failed, in which case a corrective maintenance action is initiated. However, there might be cases where a partial restoration of the inspected item would be performed during an inspection. For example, when checking the motor oil in a car between scheduled oil changes, one might occasionally add some oil in order to keep it at a constant level. The subject of inspections is discussed in more detail in Chapter 8.

=Downtime Distributions=

Maintenance actions (preventive or corrective) are not instantaneous. There is a time associated with each action (i.e. the amount of time it takes to complete the action). This time is usually referred to as downtime and it is defined as the length of time an item is not operational. There are a number of different factors that can affect the length of downtime, such as the physical characteristics of the system, spare part availability, repair crew availability, human factors, environmental factors, etc. Downtime can be divided into two categories based on these factors:
 
:• Waiting Downtime. This is the time during which the equipment is inoperable but not yet undergoing repair. This could be due to the time it takes for replacement parts to be shipped, administrative processing time, etc. 
:•Active Downtime. This is the time during which the equipment is inoperable and actually undergoing repair. In other words, the active downtime is the time it takes repair personnel to perform a repair or replacement. The length of the active downtime is greatly dependent on human factors, as well as on the design of the equipment. For example, the ease of accessibility of components in a system has a direct effect on the active downtime. 

These downtime definitions are subjective and not necessarily mutually exclusive nor all-inclusive. As an example, consider the time required to diagnose the problem. One may need to diagnose the problem before ordering parts and then wait for the parts to arrive.
 

The influence of a variety of different factors on downtime results in the fact that the time it takes to repair/restore a specific item is not generally constant. That is, the time-to-repair is a random variable, much like the time-to-failure. The statement that it takes on average five hours to repair implies an underlying probabilistic distribution. Distributions that describe the time-to-repair are called repair distributions (or downtime distributions) in order to distinguish them from the failure distributions. However, the methods employed to quantify these distributions are not any different mathematically than the methods employed to quantify failure distributions. The difference is in how they are employed (i.e. the events they describe and metrics used). As an example, when using a life distribution with failure data (i.e. the event modeled was time-to-failure), unreliability provides the probability that the event (failure) will occur by that time, while reliability provides the probability that the event (failure) will not occur. In the case of downtime distributions, the data set consists of times-to-repair, thus what we termed as unreliability now becomes the probability of the event occurring (i.e. repairing the component). Using these definitions, the probability of repairing the component by a given time, <math>t</math> , is also called the component's maintainability.

=Maintainability=
Maintainability is defined as the probability of performing a successful repair action within a given time. In other words, maintainability measures the ease and speed with which a system can be restored to operational status after a failure occurs. For example, if it is said that a particular component has a 90% maintainability in one hour, this means that there is a 90% probability that the component will be repaired within an hour. In maintainability, the random variable is time-to-repair, in the same manner as time-to-failure is the random variable in reliability. As an example, consider the maintainability equation for a system in which the repair times are distributed exponentially. Its maintainability <math>M\left( t \right)</math> is given by:
 

::<math>M\left( t \right)=1-{{e}^{-\mu \cdot t}}</math>
 

Where <math>\mu </math> = repair rate.
 

Note the similarity between this equation and the equation for the reliability of a system with exponentially distributed failure times. However, since the maintainability represents the probability of an event occurring (repairing the system) while the reliability represents the probability of an event not occurring (failure), the maintainability expression is the equivalent of the unreliability expression, <math>(1-R)</math> . Furthermore, the single model parameter <math>\mu </math> is now referred to as the repair rate, which is analogous to the failure rate, <math>\lambda </math> , used in reliability for an exponential distribution.
 

Similarly, the mean of the distribution can be obtained by:

 

::<math>\frac{1}{\mu }=MTTR\text{(mean time to repair)}</math>
 

This now becomes the mean time to repair ( <math>MTTR</math> ) instead of the mean time to failure ( <math>MTTF</math> ).
 

The same concept can be expanded to other distributions. In the case of the Weibull distribution, maintainability, <math>M\left( t \right)</math> , is given by:
 

::<math>M(t)=1-{{e}^{-{{\left( \tfrac{t}{\eta } \right)}^{\beta }}}}</math>

 

While the mean time to repair ( <math>MTTR</math> ) is given by:

 

::<math>MTTR\quad =\eta \cdot \Gamma \left( \frac{1}{\beta }+1 \right)</math>
 

And the Weibull repair rate is given by:
 

::<math>\mu (t)=\frac{\beta }{\eta }{{\left( \frac{t}{\eta } \right)}^{\beta -1}}</math>

 

As a last example, if a lognormal distribution is chosen, then:

 

::<math>M(t)=\mathop{}_{0}^{{{T}^{^{\prime }}}}\frac{1}{{{\sigma }_{{{T}'}}}\sqrt{2\pi }}{{e}^{-\tfrac{1}{2}{{\left( \tfrac{t-\overline{{{T}'}}}{{{\sigma }_{{{T}'}}}} \right)}^{2}}}}dt</math>

 

Where:
 
:• <math>\bar{{T}'}=</math> mean of the natural logarithms of the times-to-repair. 
:• <math>{{\sigma }_{{{T}'}}}=</math> standard deviation of the natural logarithms of the times-to-repair. 
 

It should be clear by now that any distribution can be used, as well as related concepts and methods used in life data analysis. The only difference being that instead of times-to-failure we are using times-to-repair. What one chooses to include in the time-to-repair varies, but can include:
 

#The time it takes to successfully diagnose the cause of the failure. 
#The time it takes to procure or deliver the parts necessary to perform the repair. 
#The time it takes to gain access to the failed part or parts. 
#The time it takes to remove the failed components and replace them with functioning ones. 
#The time involved with bringing the system back to operating status. 
#The time it takes to verify that the system is functioning within specifications. 
#The time associated with closing up a system and returning it to normal operation. 
 

In the interest of being fair and accurate, one should disclose (document) what was and was not included in determining the repair distribution.

=Availability=
If one considers both reliability (probability that the item will not fail) and maintainability (the probability that the item is successfully restored after failure), then an additional metric is needed for the probability that the component/system is operational at a given time, <math>t</math> (i.e. has not failed or it has been restored after failure). This metric is availability. Availability is a performance criterion for repairable systems that accounts for both the reliability and maintainability properties of a component or system. It is defined as the probability that the system is operating properly when it is requested for use. That is, availability is the probability that a system is not failed or undergoing a repair action when it needs to be used. For example, if a lamp has a 99.9% availability, there will be one time out of a thousand that someone needs to use the lamp and finds out that the lamp is not operational either because the lamp is burned out or the lamp is in the process of being replaced. Note that this metric alone tells us nothing about how many times the lamp has been replaced. For all we know, the lamp may be replaced every day or it could have never been replaced at all. Other metrics are still important and needed, such as the lamp's reliability. The next table illustrates the relationship between reliability, maintainability and availability.
 

[[Image:RMAtable.png|center|400px|]]
 

===A Brief Introduction to Renewal Theory===

For a repairable system, the time of operation is not continuous. In other words, its life cycle can be described by a sequence of up and down states. The system operates until it fails, then it is repaired and returned to its original operating state. It will fail again after some random time of operation, get repaired again, and this process of failure and repair will repeat. This is called a renewal process and is defined as a sequence of independent and non-negative random variables. In this case, the random variables are the times-to-failure and the times-to-repair/restore. Each time a unit fails and is restored to working order, a renewal is said to have occurred. This type of renewal process is known as an alternating renewal process because the state of the component alternates between a functioning state and a repair state, as illustrated in the following graphic.
 

[[Image:AlternatingRP.png|center|400px|]]
 

A system's renewal process is determined by the renewal processes of its components. For example, consider a series system of three statistically independent components. Each component has a failure distribution and a repair distribution. Since the components are in series, when one component fails, the entire system fails. The system is then down for as long as the failed component is under repair. Figure "System downtime as a function of three component downtimes. Components A, B, and C are in series" illustrates this.
 

[[Image:AlternatingRP2.png|center|400px|System downtime as a function of three component downtimes. Components A, B, and C are in series.]]

 
One of the main assumptions in renewal theory is that the failed components are replaced with new ones or are repaired so they are as good as new, hence the name renewal. One can make the argument that this is the case for every repair, if you define the system in enough detail. In other words, if the repair of a single circuit board in the system involves the replacement of a single transistor in the offending circuit board, then if the analysis (or RBD) is performed down to the transistor level, the transistor itself gets renewed. In cases where the analysis is done at a higher level, or if the offending component is replaced with a used component, additional steps are required. We will discuss this in later chapters using a restoration factor in the analysis. For more details on renewal theory, interested readers can refer to [[Appendix_B:_References | Elsayed [7]]] and [[Appendix_B:_References | Leemis [17]]].

===Availability Classifications===

The definition of availability is somewhat flexible and is largely based on what types of downtimes one chooses to consider in the analysis. As a result, there are a number of different classifications of availability, such as:
 
:• Instantaneous (or Point) Availability. 
:• Average Up-Time Availability (or Mean Availability). 
:• Steady State Availability. 
:• Inherent Availability. 
:• Achieved Availability. 
:• Operational Availability. 

====Instantaneous or Point Availability, <math>A\left( t \right)</math>====

Instantaneous (or point) availability is the probability that a system (or component) will be operational (up and running) at any random time, t. This is very similar to the reliability function in that it gives a probability that a system will function at the given time, t. Unlike reliability, the instantaneous availability measure incorporates maintainability information. At any given time, t, the system will be operational if the following conditions are met ([[Appendix_B:_References |Elsayed [7]]]):
 

The item functioned properly from <math>0</math> to <math>t</math> with probability <math>R(t)</math> or it functioned properly since the last repair at time u, <math>0<u<t</math> , with probability:
 

::<math>\mathop{}_{0}^{t}R(t-u)m(u)du</math>
 

With <math>m(u)</math> being the renewal density function of the system.
 

Then the point availability is the summation of these two probabilities, or:

 

::<math>A\left( t \right)=R(t)+\mathop{}_{0}^{t}R(t-u)m(u)du(eqn 1)</math>

 

====Average Uptime Availability (or Mean Availability), <math>\overline{A}\left( t \right)</math>====

The mean availability is the proportion of time during a mission or time period that the system is available for use. It represents the mean value of the instantaneous availability function over the period (0, T] and is given by:

 

::<math>\overline{A\left( t \right)}=\frac{1}{t}\mathop{}_{0}^{t}A\left( u \right)du(eqn 2)</math>

 

====Steady State Availability, <math>A(\infty )</math>====

The steady state availability of the system is the limit of the instantaneous availability function as time approaches infinity or:
 

::<math>A(\infty )=\underset{t\to \infty }{\overset{}{\mathop{\lim }}}\,A(t)(eqn 3)</math>

 

Figure "Illustration of point availiablity approaching steady state" also illustrates this graphically.
 

In other words, one can think of the steady state availability as a stabilizing point where the system's availability is a constant value. However, one has to be very careful in using the steady state availability as the sole metric for some systems, especially systems that do not need regular maintenance. A large scale system with repeated repairs, such as a car, will reach a point where it is almost certain that something will break and need repair once a month. However, this state may not be reached until, say, 500,000 miles. Obviously, if I am an operator of rental vehicles and I only keep the vehicles until they reach 50,000 miles, then this value would not be of any use to me. Similarly, if I am an auto maker and only warrant the vehicles to <math>X</math> miles, is knowing the steady state value useful?
 

[[Image:7.2.png|center|400px|Illustration of point availiablity approaching steady state.]]
 

====Inherent Availability, <math>{{A}_{I}}</math>====

Inherent availability is the steady state availability when considering only the corrective downtime of the system.
 
For a single component, this can be computed by:

 

::<math>{{A}_{I}}=\frac{MTTF}{MTTF+MTTR}</math>

 

This gets slightly more complicated for a system. To do this, one needs to look at the mean time between failures, or <math>MTBF</math> , and compute this as follows:

 

::<math>{{A}_{I}}=\frac{MTBF}{MTBF+MTTR}</math>

 

This may look simple. However, one should keep in mind that until the steady state is reached, the <math>MTBF</math> may be a function of time (e.g. a degrading system), thus the above formulation should be used cautiously. Furthermore, it is important to note that the <math>MTBF</math> defined here is different from the <math>MTTF</math> (or more precisely for a repairable system, <math>MTTFF</math> , mean time to first failure).

====Achieved Availability, <math>{{A}_{A}}</math> ====

Achieved availability is very similar to inherent availability with the exception that preventive maintenance (PM) downtimes are also included. Specifically, it is the steady state availability when considering corrective and preventive downtime of the system. It can be computed by looking at the mean time between maintenance actions, <math>MTBM,</math> and the mean maintenance downtime, <math>\overline{M},</math> or:

 

::<math>{{A}_{A}}=\frac{MTBM}{MTBM+\overline{M}}</math>

 

====Operational Availability, <math>{{A}_{o}}</math>====

Operational availability is a measure of the average availability over a period of time and it includes all experienced sources of downtime, such as administrative downtime, logistic downtime, etc.
 
Operational availability is the ratio of the system uptime and total time. Mathematically, it is given by:

 

::<math>{{A}_{o}}=\frac{Uptime}{Operating\text{ }Cycle}</math>
 

Where the operating cycle is the overall time period of operation being investigated and uptime is the total time the system was functioning during the operating cycle.
 

When there is no specified logistic downtime or preventive maintenance, equation above returns the Mean Availability of the system.
The operational availability is the availability that the customer actually experiences. It is essentially the a posteriori availability based on actual events that happened to the system. The previous availability definitions are a priori estimations based on models of the system failure and downtime distributions. In many cases, operational availability cannot be controlled by the manufacturer due to variation in location, resources and other factors that are the sole province of the end user of the product.

===Example 1===

As an example, consider the following scenario. A diesel power generator is supplying electricity at a research site in Antarctica. The personnel are not satisfied with the generator. They estimated that in the past six months, they were without electricity due to generator failure for an accumulated time of 1.5 months.
Therefore, the operational availability of the diesel generator experienced by the personnel of the station is:

 

::<math>{{A}_{o}}=\frac{4.5\text{ months}}{6\text{ months}}=0.75</math>

 

Obviously, this is not satisfactory performance for an electrical generator in such a climate, so alternatives to this source of electricity are investigated. One alternative under consideration is a wind-powered electrical turbine, which the manufacturer claims to have a 99.71% availability. This is much higher than the availability experienced by the crew of the Antarctic research station for the diesel generator. Upon investigation, it was found that the wind-turbine manufacturer estimated the availability based on the following information:
 

Failure Distribution
Exponential, <math>MTTF=2400</math> <math>hr</math>

Repair Distribution
Exponential, <math>MTTR=7</math> <math>hr</math>
 

Based on the above information, one can estimate the mean availability for the wind turbine over a period of six months to be:
 

::<math>\overline{A}={{A}_{I}}=0.9972</math>

 

This availability, however, was obtained solely by considering the claimed failure and repair properties of the wind-turbine. Waiting downtime was not considered in the above calculation. Therefore, this availability measure cannot be compared to the operational availability for the diesel generator since the two availability measurements have different inputs. This form of availability measure is also known as inherent availability. In order to make a meaningful comparison, the inherent availability of the diesel generator needs to be estimated. The diesel generator has an <math>MTTF</math> = 50 days (or 1200 hours) and an <math>MTTR</math> = 3 hours. Thus, an estimate of the mean availability is:
 

::<math>\overline{A}={{A}_{I}}=0.9975</math>

 

Note that the inherent availability of the diesel generator is actually a little bit better than the inherent availability of the wind-turbine! Even though the diesel generator has a higher failure rate, its mean-time-to-repair is much smaller than that of the wind turbine, resulting in a slightly higher inherent availability value. This example illustrates the potentially large differences in the types of availability measurements, as well as their misuse.
In this example, the operational availability is much lower than the inherent availability. This is because the inherent availability does not account for downtime due to administrative time, logistic time, the time required to obtain spare parts or the time it takes for the repair personnel to arrive at the site.

=Preventive Maintenance=
Preventive maintenance (PM) is a schedule of planned maintenance actions aimed at the prevention of breakdowns and failures. The primary goal of preventive maintenance is to prevent the failure of equipment before it actually occurs. It is designed to preserve and enhance equipment reliability by replacing worn components before they actually fail. Preventive maintenance activities include equipment checks, partial or complete overhauls at specified periods, oil changes, lubrication and so on. In addition, workers can record equipment deterioration so they know to replace or repair worn parts before they cause system failure. Recent technological advances in tools for inspection and diagnosis have enabled even more accurate and effective equipment maintenance. The ideal preventive maintenance program would prevent all equipment failure before it occurs.

===Value of Preventive Maintenance===

There are multiple misconceptions about preventive maintenance. One such misconception is that PM is unduly costly. This logic dictates that it would cost more for regularly scheduled downtime and maintenance than it would normally cost to operate equipment until repair is absolutely necessary. This may be true for some components; however, one should compare not only the costs but the long-term benefits and savings associated with preventive maintenance. Without preventive maintenance, for example, costs for lost production time from unscheduled equipment breakdown will be incurred. Also, preventive maintenance will result in savings due to an increase of effective system service life.
 

Long-term benefits of preventive maintenance include:
 
:• Improved system reliability. 
:• Decreased cost of replacement. 
:• Decreased system downtime. 
:• Better spares inventory management. 
 
Long-term effects and cost comparisons usually favor preventive maintenance over performing maintenance actions only when the system fails.

====When Does Preventive Maintenance Make Sense?====

Preventive maintenance is a logical choice if, and only if, the following two conditions are met:
 
:• Condition #1: The component in question has an increasing failure rate. In other words, the failure rate of the component increases with time, implying wear-out. Preventive maintenance of a component that is assumed to have an exponential distribution (which implies a constant failure rate) does not make sense! 
:• Condition #2: The overall cost of the preventive maintenance action must be less than the overall cost of a corrective action. 
 
If both of these conditions are met, then preventive maintenance makes sense. Additionally, based on the costs ratios, an optimum time for such action can be easily computed for a single component. This is detailed in later sections.

====The Fallacy of "Constant Failure Rate" and "Preventive Replacement"====

Even though we alluded to the fact in the last section, it is important to make it explicitly clear that if a component has a constant failure rate (i.e., defined by an exponential distribution), then preventive maintenance of the component will have no effect on the component's failure occurrences. To illustrate this, consider a component with an <math>MTTF</math> = <math>100</math> hours, or <math>\lambda =0.01</math>, and with preventive replacement every 50 hours. The reliability vs. time graph for this case is illustrated in Figure "Reliability vs. time for a single component with an <math>MTTF =100</math> hours, or <math>\lambda =0.01</math>, and with preventive replacement every 50 hours." In this figure, the component is replaced every 50 hours, thereby resetting the component's reliability to one. At first glance, it may seem that the preventive maintenance action is actually maintaining the component at a higher reliability.
 

[[Image:7i2.png|center|400px|Reliability vs. time for a single component with an <math>MTTF =100</math> hours, or <math>\lambda =0.01</math> , and with preventive replacement every 50 hours.]]
 
However, consider the following cases for a single component:
 
 
'''Case 1''': The component's reliability from 0 to 60 hours:
 

:• With preventive maintenance, the component was replaced with a new one at 50 hours so the overall reliability is based on the reliability of the new component for 10 hours, <math>R(t=10)=90.48%</math>, times the reliability of the previous component, <math>R(t=50)=60.65%</math>. The result is <math>R(t=60)=54.88%.</math> 
:• Without preventive maintenance, the reliability would be the reliability of the same component operating to 60 hours, or <math>R(t=60)=54.88%</math>. 
 
'''Case 2''': The component's reliability from 50 to 60 hours:
:• With preventive maintenance, the component was replaced at 50 hours, so this is solely based on the reliability of the new component for a mission of 10 hours, or <math>R(t=10)=90.48%</math>. 
:• Without preventive maintenance, the reliability would be the conditional reliability of the same component operating to 60 hours, having already survived to 50 hours, or <math>{{R}_{C}}(T=60|50)=R(60)/R(50)=90.48%</math> . 
 

As can be seen, both cases-- with and without preventive maintenance-- yield the same results.

===Determining Preventive Replacement Time===

As mentioned earlier, if the component has an increasing failure rate, then a carefully designed preventive maintenance program is beneficial to system availability. Otherwise, the costs of preventive maintenance might actually outweigh the benefits. The objective of a good preventive maintenance program is to either minimize the overall costs (or downtime, etc.) or meet a reliability objective. In order to achieve this, an appropriate interval (time) for scheduled maintenance must be determined. One way to do that is to use the optimum age replacement model, as presented next. The model adheres to the conditions discussed previously:
 
:• The component is exhibiting behavior associated with a wear-out mode. That is, the failure rate of the component is increasing with time. 
:• The cost for planned replacements is significantly less than the cost for unplanned replacements. 
 
Figure "Cost curves for preventive and corrective replacement" shows the Cost Per Unit Time vs. Time plot. In this figure, it can be seen that the corrective replacement costs increase as the replacement interval increases. In other words, the less often you perform a PM action, the higher your corrective costs will be. Obviously, as we let a component operate for longer times, its failure rate increases to a point that it is more likely to fail, thus requiring more corrective actions. The opposite is true for the preventive replacement costs. The longer you wait to perform a PM, the less the costs; if you do PM too often, the costs increase. If we combine both costs, we can see that there is an optimum point that minimizes the costs. In other words, one must strike a balance between the risk (costs) associated with a failure while maximizing the time between PM actions.
 

[[Image:costpertime.png|center|400px|Cost curves for preventive and corrective replacement.]]
 

===Optimum Age Replacement Policy===

To determine the optimum time for such a preventive maintenance action (replacement), we need to mathematically formulate a model that describes the associated costs and risks. In developing the model, it is assumed that if the unit fails before time <math>t</math> , a corrective action will occur and if it does not fail by time <math>t</math> , a preventive action will occur. In other words, the unit is replaced upon failure or after a time of operation, <math>t</math> , whichever occurs first.
Thus, the optimum replacement time can be found by minimizing the cost per unit time, <math>CPUT\left( t \right).</math> <math>CPUT\left( t \right)</math> is given by:
 

::<math>\begin{align}
CPUT\left( t \right)= & \frac{\text{Total Expected Replacement Cost per Cycle}}{\text{Expected Cycle Length}} \\
= & \frac{{{C}_{P}}\cdot R\left( t \right)+{{C}_{U}}\cdot \left[ 1-R\left( t \right) \right]}{\mathop{}_{0}^{t}R\left( s \right)ds}
\end{align}</math>
 

Where:
 
:• <math>R(t)</math> = reliability at time <math>t</math> . 
:• <math>{{C}_{P}}</math> = cost of planned replacement. 
:• <math>{{C}_{U}}</math> = cost of unplanned replacement. 
 
The optimum replacement time interval, <math>t</math> , is the time that minimizes <math>CPUT\left( t \right).</math> This can be found by solving for <math>t</math> such that:
 

::<math>\frac{\partial \left[ CPUT(t) \right]}{\partial t}=0</math>

 

Or by solving for a <math>t</math> that satisfies the following equation:

 

::<math>\frac{\partial \left[ \tfrac{{{C}_{P}}\cdot R\left( t \right)+{{C}_{U}}\cdot \left[ 1-R\left( t \right) \right]}{\mathop{}_{0}^{t}R\left( s \right)ds} \right]}{\partial t}=0</math>
 

Interested readers can refer to [[Appendix_B:_References |Barlow and Hunter [2]]] for more details on this model.
 

===Optimum Replacement Window in BlockSim 8===
The Optimum Replacement window in BlockSim 8 is shown in the figure below.
[[Image:optimum replacement.png|center|800px|Using BlockSim's Optimum Replacement utility to obtain the results in Example 2.]]

==== Available Blocks ====

In BlockSim 7, optimum replacement calculations were performed for individual blocks. The utility in BlockSim 8 allows you to perform calculations either for an individual block or for multiple blocks in a diagram simultaneously. When working with multiple blocks, the calculations can be for individual blocks or for one or more groups of blocks.

If you are working with a diagram instead of with a single block, the Available Blocks area on the left side of the window lists all of the standard blocks (in RBDs) or the events (in fault trees), as well as the switches for any standby containers. The following requirements must be met for an item to be available for inclusion in the optimization calculations:

*Blocks must have a failure distribution.

*Switches must have a failure model assigned. Note that in the standby configuration, the switch is the item that is optimized, not the container or the contained blocks/dependent events.

*The failure model must meet the following requirements.

:*Fixed reliability and exponential distributions are not allowed.

:*Weibull distributions must have beta > 1.

:*Gamma distributions must have k > 1.

:*Loglogistic distributions must have std < 1.

:*For generalized gamma distributions and mixed Weibull distributions, there must be an increasing failure rate within at least one time period. A local optimum can then be found within intervals with an increasing failure rate.

You can select an individual item's check box or drag the block into the table on the right side of the window to include the item in the optimization calculations. You can also select the check box in the Available Blocks header to select all check boxes. To remove items from the optimization calculations, you must clear the check box(es); you cannot drag items out of the table.

For each item that is included in the optimization calculations, you will need to specify the cost for a planned replacement and the cost for an unplanned replacement. This is done by calculating the costs for replacement based on the item settings using equations or simulation and then, if desired, manually entering any additional costs for either type of replacement in the corresponding columns of the table.

====Estimate Costs====
This calculates the costs of planned and unplanned tasks for each item based on its associated URD using the following equations.

*For the cost of planned tasks, here denoted as PM cost:

::<math>\begin{align}
\text{PM Cost}= \left(\text{PM Down Time Rate}+ \text{Block Level Down Time Rate} \right)\cdot \left( \text{MTTPM}+\text{Pool Delay} +\text{Crew Delay} \right) \\
+ \text{Crew Labor Rate} \cdot \text{MTTPM} + \text{Cost per PM} + \text{Cost per Pool} +\text{Cost per Crew}
\end{align}</math>
 

Notice: Only PM tasks based on item age are considered. If there is more than one PM task based on item age, only the first one is considered.
*For the cost of the unplanned task, here denoted as CM cost:
::<math>\begin{align}
\text{CM Cost}= \left(\text{CM Down Time Rate}+ \text{Block Level Down Time Rate} \right)\cdot \left( \text{MTTR}+\text{Pool Delay} +\text{Crew Delay} \right) \\
+ \text{Crew Labor Rate} \cdot \text{MTTR} + \text{Cost per CM} + \text{Cost per Pool} +\text{Cost per Crew} \\
+\text{Block Level Cost per Failure}
\end{align}</math>
 

The results will be used to populate the "Calculated Planned Replacement Cost" and "Calculated Unplanned Replacement Cost" columns.

====Estimate Costs Using Simulation====
This calculates the costs of planned and unplanned tasks for each item based on its associated URD using simulation. In other words, we run simulation for each item alone and estimate its costs.
When you choose this command, a Simulation Settings window is shown, allowing you to specify the simulation settings. Once the simulation settings are specified, you can estimate the costs for each item using simulation.

The results will be used to populate the "Calculated Planned Replacement Cost" and "Calculated Unplanned Replacement Cost" columns.

==== Calculate ====
If you are working with a diagram instead of with a single block, when you click Calculate, you can choose from the following options:
*Calculate the individual optimum replacement time for each item.
*Calculate a common optimum replacement time, which is the most cost-effective time to replace all of the selected items concurrently.
*Calculate clustered optimum replacement times, which allows you to specify a number of times to replace groups of the selected items. For example, if you enter 3 in the Number of clusters field, the software will determine the three best times to replace groups of items such that all of the selected items are replaced at one of the three times.

If you are working with a single block, no choice is necessary.
BlockSim will calculate the optimum replacement time for the items based on their failure characteristics and on the defined costs. This value will be displayed in the Optimum Replacement Time column of the table. In addition, the Cost per Unit Time column will display the estimated cost per unit time for a replacement performed at the calculated optimum replacement time. Multiply the replacement time by the cost per unit time to obtain the cost of replacing the item at the optimum replacement time

====Cost vs. Time Plot====
Choosing this command shows a plot of the results. If you have calculated individual optimum replacement times, the plot will show the cost for each item as a function of time. If you have calculated a common optimum replacement time, the plot will show the common cost as a function of time. If you have calculated clustered optimum replacement times, the plot will show the cost for each cluster as a function of time.

==== Create Maintenance Task(s) at Replacement Time====
This enable you to create a preventive task for one or more of the items. The window that appears allows you to select which items to create tasks for. The preventive tasks created in this way restore the item to as good as new condition and are scheduled at fixed intervals based on item age, equal to the optimum replacement time.

===Example 2===

The failure distribution of a component is described by a 2-parameter Weibull distribution with <math>\beta </math> = 2.5 and <math>\eta </math> = 1000 hours.
 
:• The cost for a corrective replacement is <math>\$5</math> . 
:• The cost for a preventive replacement is <math>\$1</math> . 
 
Estimate the optimum replacement age in order to minimize these costs.

====Solution to Example 2====

Prior to obtaining an optimum replacement interval for this component, the assumptions of the following equation must be checked.
::<math>\begin{align}
CPUT\left( t \right)= & \frac{\text{Total Expected Replacement Cost per Cycle}}{\text{Expected Cycle Length}} \\
= & \frac{{{C}_{P}}\cdot R\left( t \right)+{{C}_{U}}\cdot \left[ 1-R\left( t \right) \right]}{\mathop{}_{0}^{t}R\left( s \right)ds}
\end{align}</math>
 
The component has an increasing failure rate, since it follows a Weibull distribution with <math>\beta </math> greater than 1. Note that if <math>\beta =1</math> , then the component has a constant failure rate and if <math>\beta <1</math> , it has a decreasing failure rate. If either of these cases exist, then preventive replacement is unwise. Furthermore, the cost for preventive replacement is less than the corrective replacement cost. Thus, the conditions for the optimum age replacement policy have been met.
 

Using BlockSim, the failure parameters can be entered in the component's Block Properties window. You can then open the Optimum Replacement window and enter the costs (note that here we have to enter the costs, $1 and $5, in the "Additional Planned Replacement Cost" and "Additional Unplanned Replacement Cost" columns respectively) and compute the optimum time, <math>493.0470</math> . Figure "Using BlockSim's Optimum Replacement utility to obtain the results in Example 2" illustrates this.
 

The figure below shows a plot illustrating the cost per unit time.

[[Image:BS7.6.png|center|400px|Graph of cost vs. replacement time for Example 2.]]
 

====Discussion on Example 2====

The effect of the corrective/preventive cost ratio on the optimum replacement interval is plotted in Figure "Replacement interval as a function of the corrective/preventive cost ratio". It can be seen that as the cost ratio increases, the optimum replacement interval decreases. This is an expected result because the corrective replacement costs are much greater than the preventive replacement costs. Therefore, it becomes more cost effective to replace the component more frequently before it fails.
 
[[Image:BS7.7.png|center|400px|Replacement interval as a function of the corrective/preventive cost ratio.]]

=Applying These Principles to Larger Systems=

In this chapter, we explored some of the basic concepts and mathematical formulations involving repairable systems. Most examples/equations were given using a single component and, in some cases, using the exponential distribution for simplicity. In practical applications where one is dealing with large systems composed of many components that fail and get repaired based on different distributions and with additional constraints (such as spare parts, crews, etc.), exact analytical computations become intractable. To solve such systems, one needs to resort to simulation (more specifically, discrete event simulation) to obtain the metrics/results discussed in this section. The next chapter expands on these concepts and introduces these simulation methods.

File:BS7.6.png

2012-03-30T20:57:33Z

Nikki Helms: uploaded a new version of "File:BS7.6.png"

Introduction to Repairable Systems

2012-03-30T20:57:05Z

Nikki Helms: /* Solution to Example 2 */

{{Template:bsbook|7}}

=Repairable Systems=

In prior chapters, the analysis was focused on determining the reliability of the system (i.e. the probability that the system, subsystem or component will operate successfully by a given time, <math>t</math> .) The prior formulations provided us with the probability of success of the entire system, up to a point in time, without looking at the question: ``What happens if a component fails during that time and is then fixed?'' In dealing with repairable systems, these definitions need to be redefined and adapted to deal with this case of the renewal of systems/components.
 

Repairable systems receive maintenance actions that restore/renew system components when they fail. These actions change the overall makeup of the system. These actions must now be taken into consideration when assessing the behavior of the system because the age of the system components is no longer uniform nor is the time of operation of the system continuous.
 

In attempting to understand the system behavior, additional information and models are now needed for each system component. Our primary input in the prior chapters was a model that described how the component failed (its failure probability distribution). When dealing with components that are repaired, one also needs to know how long it takes for the component to be restored. That is, at the very least, one needs a model that describes how the component is restored (a repair probability distribution).
 

In this chapter, we will introduce the additional information, models and metrics required to fully analyze a repairable system.

[[Category:Completed Theoretical Review]]

=Defining Maintenance=

To properly deal with repairable systems, we need to first understand how components in these systems are restored (i.e. the maintenance actions that the components undergo). In general, maintenance is defined as any action that restores failed units to an operational condition or retains non-failed units in an operational state. For repairable systems, maintenance plays a vital role in the life of a system. It affects the system's overall reliability, availability, downtime, cost of operation, etc. Generally, maintenance actions can be divided into three types: corrective maintenance, preventive maintenance and inspections.

===Corrective Maintenance===

Corrective maintenance consists of the action(s) taken to restore a failed system to operational status. This usually involves replacing or repairing the component that is responsible for the failure of the overall system. Corrective maintenance is performed at unpredictable intervals because a component's failure time is not known a priori. The objective of corrective maintenance is to restore the system to satisfactory operation within the shortest possible time. Corrective maintenance is typically carried out in three steps:
 

:• Diagnosis of the problem. The maintenance technician must take time to locate the failed parts or otherwise satisfactorily assess the cause of the system failure. 
:• Repair and/or replacement of faulty component(s). Once the cause of system failure has been determined, action must be taken to address the cause, usually by replacing or repairing the components that caused the system to fail. 
:• Verification of the repair action. Once the components in question have been repaired or replaced, the maintenance technician must verify that the system is again successfully operating. 
 

===Preventive Maintenance===

Preventive maintenance, unlike corrective maintenance, is the practice of replacing components or subsystems before they fail in order to promote continuous system operation. The schedule for preventive maintenance is based on observation of past system behavior, component wear-out mechanisms and knowledge of which components are vital to continued system operation. Cost is always a factor in the scheduling of preventive maintenance. In many circumstances, it is financially more sensible to replace parts or components that have not failed at predetermined intervals rather than to wait for a system failure that may result in a costly disruption in operations. Preventive maintenance scheduling strategies are discussed in more detail later in this chapter.

===Inspections===

Inspections are used in order to uncover hidden failures (also called dormant failures). In general, no maintenance action is performed on the component during an inspection unless the component is found failed, in which case a corrective maintenance action is initiated. However, there might be cases where a partial restoration of the inspected item would be performed during an inspection. For example, when checking the motor oil in a car between scheduled oil changes, one might occasionally add some oil in order to keep it at a constant level. The subject of inspections is discussed in more detail in Chapter 8.

=Downtime Distributions=

Maintenance actions (preventive or corrective) are not instantaneous. There is a time associated with each action (i.e. the amount of time it takes to complete the action). This time is usually referred to as downtime and it is defined as the length of time an item is not operational. There are a number of different factors that can affect the length of downtime, such as the physical characteristics of the system, spare part availability, repair crew availability, human factors, environmental factors, etc. Downtime can be divided into two categories based on these factors:
 
:• Waiting Downtime. This is the time during which the equipment is inoperable but not yet undergoing repair. This could be due to the time it takes for replacement parts to be shipped, administrative processing time, etc. 
:•Active Downtime. This is the time during which the equipment is inoperable and actually undergoing repair. In other words, the active downtime is the time it takes repair personnel to perform a repair or replacement. The length of the active downtime is greatly dependent on human factors, as well as on the design of the equipment. For example, the ease of accessibility of components in a system has a direct effect on the active downtime. 

These downtime definitions are subjective and not necessarily mutually exclusive nor all-inclusive. As an example, consider the time required to diagnose the problem. One may need to diagnose the problem before ordering parts and then wait for the parts to arrive.
 

The influence of a variety of different factors on downtime results in the fact that the time it takes to repair/restore a specific item is not generally constant. That is, the time-to-repair is a random variable, much like the time-to-failure. The statement that it takes on average five hours to repair implies an underlying probabilistic distribution. Distributions that describe the time-to-repair are called repair distributions (or downtime distributions) in order to distinguish them from the failure distributions. However, the methods employed to quantify these distributions are not any different mathematically than the methods employed to quantify failure distributions. The difference is in how they are employed (i.e. the events they describe and metrics used). As an example, when using a life distribution with failure data (i.e. the event modeled was time-to-failure), unreliability provides the probability that the event (failure) will occur by that time, while reliability provides the probability that the event (failure) will not occur. In the case of downtime distributions, the data set consists of times-to-repair, thus what we termed as unreliability now becomes the probability of the event occurring (i.e. repairing the component). Using these definitions, the probability of repairing the component by a given time, <math>t</math> , is also called the component's maintainability.

=Maintainability=
Maintainability is defined as the probability of performing a successful repair action within a given time. In other words, maintainability measures the ease and speed with which a system can be restored to operational status after a failure occurs. For example, if it is said that a particular component has a 90% maintainability in one hour, this means that there is a 90% probability that the component will be repaired within an hour. In maintainability, the random variable is time-to-repair, in the same manner as time-to-failure is the random variable in reliability. As an example, consider the maintainability equation for a system in which the repair times are distributed exponentially. Its maintainability <math>M\left( t \right)</math> is given by:
 

::<math>M\left( t \right)=1-{{e}^{-\mu \cdot t}}</math>
 

Where <math>\mu </math> = repair rate.
 

Note the similarity between this equation and the equation for the reliability of a system with exponentially distributed failure times. However, since the maintainability represents the probability of an event occurring (repairing the system) while the reliability represents the probability of an event not occurring (failure), the maintainability expression is the equivalent of the unreliability expression, <math>(1-R)</math> . Furthermore, the single model parameter <math>\mu </math> is now referred to as the repair rate, which is analogous to the failure rate, <math>\lambda </math> , used in reliability for an exponential distribution.
 

Similarly, the mean of the distribution can be obtained by:

 

::<math>\frac{1}{\mu }=MTTR\text{(mean time to repair)}</math>
 

This now becomes the mean time to repair ( <math>MTTR</math> ) instead of the mean time to failure ( <math>MTTF</math> ).
 

The same concept can be expanded to other distributions. In the case of the Weibull distribution, maintainability, <math>M\left( t \right)</math> , is given by:
 

::<math>M(t)=1-{{e}^{-{{\left( \tfrac{t}{\eta } \right)}^{\beta }}}}</math>

 

While the mean time to repair ( <math>MTTR</math> ) is given by:

 

::<math>MTTR\quad =\eta \cdot \Gamma \left( \frac{1}{\beta }+1 \right)</math>
 

And the Weibull repair rate is given by:
 

::<math>\mu (t)=\frac{\beta }{\eta }{{\left( \frac{t}{\eta } \right)}^{\beta -1}}</math>

 

As a last example, if a lognormal distribution is chosen, then:

 

::<math>M(t)=\mathop{}_{0}^{{{T}^{^{\prime }}}}\frac{1}{{{\sigma }_{{{T}'}}}\sqrt{2\pi }}{{e}^{-\tfrac{1}{2}{{\left( \tfrac{t-\overline{{{T}'}}}{{{\sigma }_{{{T}'}}}} \right)}^{2}}}}dt</math>

 

Where:
 
:• <math>\bar{{T}'}=</math> mean of the natural logarithms of the times-to-repair. 
:• <math>{{\sigma }_{{{T}'}}}=</math> standard deviation of the natural logarithms of the times-to-repair. 
 

It should be clear by now that any distribution can be used, as well as related concepts and methods used in life data analysis. The only difference being that instead of times-to-failure we are using times-to-repair. What one chooses to include in the time-to-repair varies, but can include:
 

#The time it takes to successfully diagnose the cause of the failure. 
#The time it takes to procure or deliver the parts necessary to perform the repair. 
#The time it takes to gain access to the failed part or parts. 
#The time it takes to remove the failed components and replace them with functioning ones. 
#The time involved with bringing the system back to operating status. 
#The time it takes to verify that the system is functioning within specifications. 
#The time associated with closing up a system and returning it to normal operation. 
 

In the interest of being fair and accurate, one should disclose (document) what was and was not included in determining the repair distribution.

=Availability=
If one considers both reliability (probability that the item will not fail) and maintainability (the probability that the item is successfully restored after failure), then an additional metric is needed for the probability that the component/system is operational at a given time, <math>t</math> (i.e. has not failed or it has been restored after failure). This metric is availability. Availability is a performance criterion for repairable systems that accounts for both the reliability and maintainability properties of a component or system. It is defined as the probability that the system is operating properly when it is requested for use. That is, availability is the probability that a system is not failed or undergoing a repair action when it needs to be used. For example, if a lamp has a 99.9% availability, there will be one time out of a thousand that someone needs to use the lamp and finds out that the lamp is not operational either because the lamp is burned out or the lamp is in the process of being replaced. Note that this metric alone tells us nothing about how many times the lamp has been replaced. For all we know, the lamp may be replaced every day or it could have never been replaced at all. Other metrics are still important and needed, such as the lamp's reliability. The next table illustrates the relationship between reliability, maintainability and availability.
 

[[Image:RMAtable.png|center|400px|]]
 

===A Brief Introduction to Renewal Theory===

For a repairable system, the time of operation is not continuous. In other words, its life cycle can be described by a sequence of up and down states. The system operates until it fails, then it is repaired and returned to its original operating state. It will fail again after some random time of operation, get repaired again, and this process of failure and repair will repeat. This is called a renewal process and is defined as a sequence of independent and non-negative random variables. In this case, the random variables are the times-to-failure and the times-to-repair/restore. Each time a unit fails and is restored to working order, a renewal is said to have occurred. This type of renewal process is known as an alternating renewal process because the state of the component alternates between a functioning state and a repair state, as illustrated in the following graphic.
 

[[Image:AlternatingRP.png|center|400px|]]
 

A system's renewal process is determined by the renewal processes of its components. For example, consider a series system of three statistically independent components. Each component has a failure distribution and a repair distribution. Since the components are in series, when one component fails, the entire system fails. The system is then down for as long as the failed component is under repair. Figure "System downtime as a function of three component downtimes. Components A, B, and C are in series" illustrates this.
 

[[Image:AlternatingRP2.png|center|400px|System downtime as a function of three component downtimes. Components A, B, and C are in series.]]

 
One of the main assumptions in renewal theory is that the failed components are replaced with new ones or are repaired so they are as good as new, hence the name renewal. One can make the argument that this is the case for every repair, if you define the system in enough detail. In other words, if the repair of a single circuit board in the system involves the replacement of a single transistor in the offending circuit board, then if the analysis (or RBD) is performed down to the transistor level, the transistor itself gets renewed. In cases where the analysis is done at a higher level, or if the offending component is replaced with a used component, additional steps are required. We will discuss this in later chapters using a restoration factor in the analysis. For more details on renewal theory, interested readers can refer to [[Appendix_B:_References | Elsayed [7]]] and [[Appendix_B:_References | Leemis [17]]].

===Availability Classifications===

The definition of availability is somewhat flexible and is largely based on what types of downtimes one chooses to consider in the analysis. As a result, there are a number of different classifications of availability, such as:
 
:• Instantaneous (or Point) Availability. 
:• Average Up-Time Availability (or Mean Availability). 
:• Steady State Availability. 
:• Inherent Availability. 
:• Achieved Availability. 
:• Operational Availability. 

====Instantaneous or Point Availability, <math>A\left( t \right)</math>====

Instantaneous (or point) availability is the probability that a system (or component) will be operational (up and running) at any random time, t. This is very similar to the reliability function in that it gives a probability that a system will function at the given time, t. Unlike reliability, the instantaneous availability measure incorporates maintainability information. At any given time, t, the system will be operational if the following conditions are met ([[Appendix_B:_References |Elsayed [7]]]):
 

The item functioned properly from <math>0</math> to <math>t</math> with probability <math>R(t)</math> or it functioned properly since the last repair at time u, <math>0<u<t</math> , with probability:
 

::<math>\mathop{}_{0}^{t}R(t-u)m(u)du</math>
 

With <math>m(u)</math> being the renewal density function of the system.
 

Then the point availability is the summation of these two probabilities, or:

 

::<math>A\left( t \right)=R(t)+\mathop{}_{0}^{t}R(t-u)m(u)du(eqn 1)</math>

 

====Average Uptime Availability (or Mean Availability), <math>\overline{A}\left( t \right)</math>====

The mean availability is the proportion of time during a mission or time period that the system is available for use. It represents the mean value of the instantaneous availability function over the period (0, T] and is given by:

 

::<math>\overline{A\left( t \right)}=\frac{1}{t}\mathop{}_{0}^{t}A\left( u \right)du(eqn 2)</math>

 

====Steady State Availability, <math>A(\infty )</math>====

The steady state availability of the system is the limit of the instantaneous availability function as time approaches infinity or:
 

::<math>A(\infty )=\underset{t\to \infty }{\overset{}{\mathop{\lim }}}\,A(t)(eqn 3)</math>

 

Figure "Illustration of point availiablity approaching steady state" also illustrates this graphically.
 

In other words, one can think of the steady state availability as a stabilizing point where the system's availability is a constant value. However, one has to be very careful in using the steady state availability as the sole metric for some systems, especially systems that do not need regular maintenance. A large scale system with repeated repairs, such as a car, will reach a point where it is almost certain that something will break and need repair once a month. However, this state may not be reached until, say, 500,000 miles. Obviously, if I am an operator of rental vehicles and I only keep the vehicles until they reach 50,000 miles, then this value would not be of any use to me. Similarly, if I am an auto maker and only warrant the vehicles to <math>X</math> miles, is knowing the steady state value useful?
 

[[Image:7.2.png|center|400px|Illustration of point availiablity approaching steady state.]]
 

====Inherent Availability, <math>{{A}_{I}}</math>====

Inherent availability is the steady state availability when considering only the corrective downtime of the system.
 
For a single component, this can be computed by:

 

::<math>{{A}_{I}}=\frac{MTTF}{MTTF+MTTR}</math>

 

This gets slightly more complicated for a system. To do this, one needs to look at the mean time between failures, or <math>MTBF</math> , and compute this as follows:

 

::<math>{{A}_{I}}=\frac{MTBF}{MTBF+MTTR}</math>

 

This may look simple. However, one should keep in mind that until the steady state is reached, the <math>MTBF</math> may be a function of time (e.g. a degrading system), thus the above formulation should be used cautiously. Furthermore, it is important to note that the <math>MTBF</math> defined here is different from the <math>MTTF</math> (or more precisely for a repairable system, <math>MTTFF</math> , mean time to first failure).

====Achieved Availability, <math>{{A}_{A}}</math> ====

Achieved availability is very similar to inherent availability with the exception that preventive maintenance (PM) downtimes are also included. Specifically, it is the steady state availability when considering corrective and preventive downtime of the system. It can be computed by looking at the mean time between maintenance actions, <math>MTBM,</math> and the mean maintenance downtime, <math>\overline{M},</math> or:

 

::<math>{{A}_{A}}=\frac{MTBM}{MTBM+\overline{M}}</math>

 

====Operational Availability, <math>{{A}_{o}}</math>====

Operational availability is a measure of the average availability over a period of time and it includes all experienced sources of downtime, such as administrative downtime, logistic downtime, etc.
 
Operational availability is the ratio of the system uptime and total time. Mathematically, it is given by:

 

::<math>{{A}_{o}}=\frac{Uptime}{Operating\text{ }Cycle}</math>
 

Where the operating cycle is the overall time period of operation being investigated and uptime is the total time the system was functioning during the operating cycle.
 

When there is no specified logistic downtime or preventive maintenance, equation above returns the Mean Availability of the system.
The operational availability is the availability that the customer actually experiences. It is essentially the a posteriori availability based on actual events that happened to the system. The previous availability definitions are a priori estimations based on models of the system failure and downtime distributions. In many cases, operational availability cannot be controlled by the manufacturer due to variation in location, resources and other factors that are the sole province of the end user of the product.

===Example 1===

As an example, consider the following scenario. A diesel power generator is supplying electricity at a research site in Antarctica. The personnel are not satisfied with the generator. They estimated that in the past six months, they were without electricity due to generator failure for an accumulated time of 1.5 months.
Therefore, the operational availability of the diesel generator experienced by the personnel of the station is:

 

::<math>{{A}_{o}}=\frac{4.5\text{ months}}{6\text{ months}}=0.75</math>

 

Obviously, this is not satisfactory performance for an electrical generator in such a climate, so alternatives to this source of electricity are investigated. One alternative under consideration is a wind-powered electrical turbine, which the manufacturer claims to have a 99.71% availability. This is much higher than the availability experienced by the crew of the Antarctic research station for the diesel generator. Upon investigation, it was found that the wind-turbine manufacturer estimated the availability based on the following information:
 

Failure Distribution
Exponential, <math>MTTF=2400</math> <math>hr</math>

Repair Distribution
Exponential, <math>MTTR=7</math> <math>hr</math>
 

Based on the above information, one can estimate the mean availability for the wind turbine over a period of six months to be:
 

::<math>\overline{A}={{A}_{I}}=0.9972</math>

 

This availability, however, was obtained solely by considering the claimed failure and repair properties of the wind-turbine. Waiting downtime was not considered in the above calculation. Therefore, this availability measure cannot be compared to the operational availability for the diesel generator since the two availability measurements have different inputs. This form of availability measure is also known as inherent availability. In order to make a meaningful comparison, the inherent availability of the diesel generator needs to be estimated. The diesel generator has an <math>MTTF</math> = 50 days (or 1200 hours) and an <math>MTTR</math> = 3 hours. Thus, an estimate of the mean availability is:
 

::<math>\overline{A}={{A}_{I}}=0.9975</math>

 

Note that the inherent availability of the diesel generator is actually a little bit better than the inherent availability of the wind-turbine! Even though the diesel generator has a higher failure rate, its mean-time-to-repair is much smaller than that of the wind turbine, resulting in a slightly higher inherent availability value. This example illustrates the potentially large differences in the types of availability measurements, as well as their misuse.
In this example, the operational availability is much lower than the inherent availability. This is because the inherent availability does not account for downtime due to administrative time, logistic time, the time required to obtain spare parts or the time it takes for the repair personnel to arrive at the site.

=Preventive Maintenance=
Preventive maintenance (PM) is a schedule of planned maintenance actions aimed at the prevention of breakdowns and failures. The primary goal of preventive maintenance is to prevent the failure of equipment before it actually occurs. It is designed to preserve and enhance equipment reliability by replacing worn components before they actually fail. Preventive maintenance activities include equipment checks, partial or complete overhauls at specified periods, oil changes, lubrication and so on. In addition, workers can record equipment deterioration so they know to replace or repair worn parts before they cause system failure. Recent technological advances in tools for inspection and diagnosis have enabled even more accurate and effective equipment maintenance. The ideal preventive maintenance program would prevent all equipment failure before it occurs.

===Value of Preventive Maintenance===

There are multiple misconceptions about preventive maintenance. One such misconception is that PM is unduly costly. This logic dictates that it would cost more for regularly scheduled downtime and maintenance than it would normally cost to operate equipment until repair is absolutely necessary. This may be true for some components; however, one should compare not only the costs but the long-term benefits and savings associated with preventive maintenance. Without preventive maintenance, for example, costs for lost production time from unscheduled equipment breakdown will be incurred. Also, preventive maintenance will result in savings due to an increase of effective system service life.
 

Long-term benefits of preventive maintenance include:
 
:• Improved system reliability. 
:• Decreased cost of replacement. 
:• Decreased system downtime. 
:• Better spares inventory management. 
 
Long-term effects and cost comparisons usually favor preventive maintenance over performing maintenance actions only when the system fails.

====When Does Preventive Maintenance Make Sense?====

Preventive maintenance is a logical choice if, and only if, the following two conditions are met:
 
:• Condition #1: The component in question has an increasing failure rate. In other words, the failure rate of the component increases with time, implying wear-out. Preventive maintenance of a component that is assumed to have an exponential distribution (which implies a constant failure rate) does not make sense! 
:• Condition #2: The overall cost of the preventive maintenance action must be less than the overall cost of a corrective action. 
 
If both of these conditions are met, then preventive maintenance makes sense. Additionally, based on the costs ratios, an optimum time for such action can be easily computed for a single component. This is detailed in later sections.

====The Fallacy of "Constant Failure Rate" and "Preventive Replacement"====

Even though we alluded to the fact in the last section, it is important to make it explicitly clear that if a component has a constant failure rate (i.e., defined by an exponential distribution), then preventive maintenance of the component will have no effect on the component's failure occurrences. To illustrate this, consider a component with an <math>MTTF</math> = <math>100</math> hours, or <math>\lambda =0.01</math>, and with preventive replacement every 50 hours. The reliability vs. time graph for this case is illustrated in Figure "Reliability vs. time for a single component with an <math>MTTF =100</math> hours, or <math>\lambda =0.01</math>, and with preventive replacement every 50 hours." In this figure, the component is replaced every 50 hours, thereby resetting the component's reliability to one. At first glance, it may seem that the preventive maintenance action is actually maintaining the component at a higher reliability.
 

[[Image:7i2.png|center|400px|Reliability vs. time for a single component with an <math>MTTF =100</math> hours, or <math>\lambda =0.01</math> , and with preventive replacement every 50 hours.]]
 
However, consider the following cases for a single component:
 
 
'''Case 1''': The component's reliability from 0 to 60 hours:
 

:• With preventive maintenance, the component was replaced with a new one at 50 hours so the overall reliability is based on the reliability of the new component for 10 hours, <math>R(t=10)=90.48%</math>, times the reliability of the previous component, <math>R(t=50)=60.65%</math>. The result is <math>R(t=60)=54.88%.</math> 
:• Without preventive maintenance, the reliability would be the reliability of the same component operating to 60 hours, or <math>R(t=60)=54.88%</math>. 
 
'''Case 2''': The component's reliability from 50 to 60 hours:
:• With preventive maintenance, the component was replaced at 50 hours, so this is solely based on the reliability of the new component for a mission of 10 hours, or <math>R(t=10)=90.48%</math>. 
:• Without preventive maintenance, the reliability would be the conditional reliability of the same component operating to 60 hours, having already survived to 50 hours, or <math>{{R}_{C}}(T=60|50)=R(60)/R(50)=90.48%</math> . 
 

As can be seen, both cases-- with and without preventive maintenance-- yield the same results.

===Determining Preventive Replacement Time===

As mentioned earlier, if the component has an increasing failure rate, then a carefully designed preventive maintenance program is beneficial to system availability. Otherwise, the costs of preventive maintenance might actually outweigh the benefits. The objective of a good preventive maintenance program is to either minimize the overall costs (or downtime, etc.) or meet a reliability objective. In order to achieve this, an appropriate interval (time) for scheduled maintenance must be determined. One way to do that is to use the optimum age replacement model, as presented next. The model adheres to the conditions discussed previously:
 
:• The component is exhibiting behavior associated with a wear-out mode. That is, the failure rate of the component is increasing with time. 
:• The cost for planned replacements is significantly less than the cost for unplanned replacements. 
 
Figure "Cost curves for preventive and corrective replacement" shows the Cost Per Unit Time vs. Time plot. In this figure, it can be seen that the corrective replacement costs increase as the replacement interval increases. In other words, the less often you perform a PM action, the higher your corrective costs will be. Obviously, as we let a component operate for longer times, its failure rate increases to a point that it is more likely to fail, thus requiring more corrective actions. The opposite is true for the preventive replacement costs. The longer you wait to perform a PM, the less the costs; if you do PM too often, the costs increase. If we combine both costs, we can see that there is an optimum point that minimizes the costs. In other words, one must strike a balance between the risk (costs) associated with a failure while maximizing the time between PM actions.
 

[[Image:costpertime.png|center|400px|Cost curves for preventive and corrective replacement.]]
 

===Optimum Age Replacement Policy===

To determine the optimum time for such a preventive maintenance action (replacement), we need to mathematically formulate a model that describes the associated costs and risks. In developing the model, it is assumed that if the unit fails before time <math>t</math> , a corrective action will occur and if it does not fail by time <math>t</math> , a preventive action will occur. In other words, the unit is replaced upon failure or after a time of operation, <math>t</math> , whichever occurs first.
Thus, the optimum replacement time can be found by minimizing the cost per unit time, <math>CPUT\left( t \right).</math> <math>CPUT\left( t \right)</math> is given by:
 

::<math>\begin{align}
CPUT\left( t \right)= & \frac{\text{Total Expected Replacement Cost per Cycle}}{\text{Expected Cycle Length}} \\
= & \frac{{{C}_{P}}\cdot R\left( t \right)+{{C}_{U}}\cdot \left[ 1-R\left( t \right) \right]}{\mathop{}_{0}^{t}R\left( s \right)ds}
\end{align}</math>
 

Where:
 
:• <math>R(t)</math> = reliability at time <math>t</math> . 
:• <math>{{C}_{P}}</math> = cost of planned replacement. 
:• <math>{{C}_{U}}</math> = cost of unplanned replacement. 
 
The optimum replacement time interval, <math>t</math> , is the time that minimizes <math>CPUT\left( t \right).</math> This can be found by solving for <math>t</math> such that:
 

::<math>\frac{\partial \left[ CPUT(t) \right]}{\partial t}=0</math>

 

Or by solving for a <math>t</math> that satisfies the following equation:

 

::<math>\frac{\partial \left[ \tfrac{{{C}_{P}}\cdot R\left( t \right)+{{C}_{U}}\cdot \left[ 1-R\left( t \right) \right]}{\mathop{}_{0}^{t}R\left( s \right)ds} \right]}{\partial t}=0</math>
 

Interested readers can refer to [[Appendix_B:_References |Barlow and Hunter [2]]] for more details on this model.
 

===Optimum Replacement Window in BlockSim 8===
The Optimum Replacement window in BlockSim 8 is shown in the figure below.
[[Image:optimum replacement.png|center|800px|Using BlockSim's Optimum Replacement utility to obtain the results in Example 2.]]

==== Available Blocks ====

In BlockSim 7, optimum replacement calculations were performed for individual blocks. The utility in BlockSim 8 allows you to perform calculations either for an individual block or for multiple blocks in a diagram simultaneously. When working with multiple blocks, the calculations can be for individual blocks or for one or more groups of blocks.

If you are working with a diagram instead of with a single block, the Available Blocks area on the left side of the window lists all of the standard blocks (in RBDs) or the events (in fault trees), as well as the switches for any standby containers. The following requirements must be met for an item to be available for inclusion in the optimization calculations:

*Blocks must have a failure distribution.

*Switches must have a failure model assigned. Note that in the standby configuration, the switch is the item that is optimized, not the container or the contained blocks/dependent events.

*The failure model must meet the following requirements.

:*Fixed reliability and exponential distributions are not allowed.

:*Weibull distributions must have beta > 1.

:*Gamma distributions must have k > 1.

:*Loglogistic distributions must have std < 1.

:*For generalized gamma distributions and mixed Weibull distributions, there must be an increasing failure rate within at least one time period. A local optimum can then be found within intervals with an increasing failure rate.

You can select an individual item's check box or drag the block into the table on the right side of the window to include the item in the optimization calculations. You can also select the check box in the Available Blocks header to select all check boxes. To remove items from the optimization calculations, you must clear the check box(es); you cannot drag items out of the table.

For each item that is included in the optimization calculations, you will need to specify the cost for a planned replacement and the cost for an unplanned replacement. This is done by calculating the costs for replacement based on the item settings using equations or simulation and then, if desired, manually entering any additional costs for either type of replacement in the corresponding columns of the table.

====Estimate Costs====
This calculates the costs of planned and unplanned tasks for each item based on its associated URD using the following equations.

*For the cost of planned tasks, here denoted as PM cost:

::<math>\begin{align}
\text{PM Cost}= \left(\text{PM Down Time Rate}+ \text{Block Level Down Time Rate} \right)\cdot \left( \text{MTTPM}+\text{Pool Delay} +\text{Crew Delay} \right) \\
+ \text{Crew Labor Rate} \cdot \text{MTTPM} + \text{Cost per PM} + \text{Cost per Pool} +\text{Cost per Crew}
\end{align}</math>
 

Notice: Only PM tasks based on item age are considered. If there is more than one PM task based on item age, only the first one is considered.
*For the cost of the unplanned task, here denoted as CM cost:
::<math>\begin{align}
\text{CM Cost}= \left(\text{CM Down Time Rate}+ \text{Block Level Down Time Rate} \right)\cdot \left( \text{MTTR}+\text{Pool Delay} +\text{Crew Delay} \right) \\
+ \text{Crew Labor Rate} \cdot \text{MTTR} + \text{Cost per CM} + \text{Cost per Pool} +\text{Cost per Crew} \\
+\text{Block Level Cost per Failure}
\end{align}</math>
 

The results will be used to populate the "Calculated Planned Replacement Cost" and "Calculated Unplanned Replacement Cost" columns.

====Estimate Costs Using Simulation====
This calculates the costs of planned and unplanned tasks for each item based on its associated URD using simulation. In other words, we run simulation for each item alone and estimate its costs.
When you choose this command, a Simulation Settings window is shown, allowing you to specify the simulation settings. Once the simulation settings are specified, you can estimate the costs for each item using simulation.

The results will be used to populate the "Calculated Planned Replacement Cost" and "Calculated Unplanned Replacement Cost" columns.

==== Calculate ====
If you are working with a diagram instead of with a single block, when you click Calculate, you can choose from the following options:
*Calculate the individual optimum replacement time for each item.
*Calculate a common optimum replacement time, which is the most cost-effective time to replace all of the selected items concurrently.
*Calculate clustered optimum replacement times, which allows you to specify a number of times to replace groups of the selected items. For example, if you enter 3 in the Number of clusters field, the software will determine the three best times to replace groups of items such that all of the selected items are replaced at one of the three times.

If you are working with a single block, no choice is necessary.
BlockSim will calculate the optimum replacement time for the items based on their failure characteristics and on the defined costs. This value will be displayed in the Optimum Replacement Time column of the table. In addition, the Cost per Unit Time column will display the estimated cost per unit time for a replacement performed at the calculated optimum replacement time. Multiply the replacement time by the cost per unit time to obtain the cost of replacing the item at the optimum replacement time

====Cost vs. Time Plot====
Choosing this command shows a plot of the results. If you have calculated individual optimum replacement times, the plot will show the cost for each item as a function of time. If you have calculated a common optimum replacement time, the plot will show the common cost as a function of time. If you have calculated clustered optimum replacement times, the plot will show the cost for each cluster as a function of time.

==== Create Maintenance Task(s) at Replacement Time====
This enable you to create a preventive task for one or more of the items. The window that appears allows you to select which items to create tasks for. The preventive tasks created in this way restore the item to as good as new condition and are scheduled at fixed intervals based on item age, equal to the optimum replacement time.

===Example 2===

The failure distribution of a component is described by a 2-parameter Weibull distribution with <math>\beta </math> = 2.5 and <math>\eta </math> = 1000 hours.
 
:• The cost for a corrective replacement is <math>\$5</math> . 
:• The cost for a preventive replacement is <math>\$1</math> . 
 
Estimate the optimum replacement age in order to minimize these costs.

====Solution to Example 2====

Prior to obtaining an optimum replacement interval for this component, the assumptions of the following equation must be checked.
::<math>\begin{align}
CPUT\left( t \right)= & \frac{\text{Total Expected Replacement Cost per Cycle}}{\text{Expected Cycle Length}} \\
= & \frac{{{C}_{P}}\cdot R\left( t \right)+{{C}_{U}}\cdot \left[ 1-R\left( t \right) \right]}{\mathop{}_{0}^{t}R\left( s \right)ds}
\end{align}</math>
 
The component has an increasing failure rate, since it follows a Weibull distribution with <math>\beta </math> greater than 1. Note that if <math>\beta =1</math> , then the component has a constant failure rate and if <math>\beta <1</math> , it has a decreasing failure rate. If either of these cases exist, then preventive replacement is unwise. Furthermore, the cost for preventive replacement is less than the corrective replacement cost. Thus, the conditions for the optimum age replacement policy have been met.
 

Using BlockSim, the failure parameters can be entered in the component's Block Properties window. You can then open the Optimum Replacement window and enter the costs (note that here we have to enter the costs, $1 and $5, in the "Additional Planned Replacement Cost" and "Additional Unplanned Replacement Cost" columns respectively) and compute the optimum time, <math>493.0470</math> . Figure "Using BlockSim's Optimum Replacement utility to obtain the results in Example 2" illustrates this.
 

The figure below shows a plot illustrating the cost per unit time.

[[Image:BS7.6.png|center|400px|Graph of cost vs. replacement time for Example 2.]]
 

====Discussion on Example 2====

The effect of the corrective/preventive cost ratio on the optimum replacement interval is plotted in Figure "Replacement interval as a function of the corrective/preventive cost ratio". It can be seen that as the cost ratio increases, the optimum replacement interval decreases. This is an expected result because the corrective replacement costs are much greater than the preventive replacement costs. Therefore, it becomes more cost effective to replace the component more frequently before it fails.
 
[[Image:BS7.7.png|thumb|center|400px|Replacement interval as a function of the corrective/preventive cost ratio.]]

=Applying These Principles to Larger Systems=

In this chapter, we explored some of the basic concepts and mathematical formulations involving repairable systems. Most examples/equations were given using a single component and, in some cases, using the exponential distribution for simplicity. In practical applications where one is dealing with large systems composed of many components that fail and get repaired based on different distributions and with additional constraints (such as spare parts, crews, etc.), exact analytical computations become intractable. To solve such systems, one needs to resort to simulation (more specifically, discrete event simulation) to obtain the metrics/results discussed in this section. The next chapter expands on these concepts and introduces these simulation methods.

Introduction to Repairable Systems

2012-03-30T20:56:46Z

Nikki Helms: /* Optimum Replacement Window in BlockSim 8 */

{{Template:bsbook|7}}

=Repairable Systems=

In prior chapters, the analysis was focused on determining the reliability of the system (i.e. the probability that the system, subsystem or component will operate successfully by a given time, <math>t</math> .) The prior formulations provided us with the probability of success of the entire system, up to a point in time, without looking at the question: ``What happens if a component fails during that time and is then fixed?'' In dealing with repairable systems, these definitions need to be redefined and adapted to deal with this case of the renewal of systems/components.
 

Repairable systems receive maintenance actions that restore/renew system components when they fail. These actions change the overall makeup of the system. These actions must now be taken into consideration when assessing the behavior of the system because the age of the system components is no longer uniform nor is the time of operation of the system continuous.
 

In attempting to understand the system behavior, additional information and models are now needed for each system component. Our primary input in the prior chapters was a model that described how the component failed (its failure probability distribution). When dealing with components that are repaired, one also needs to know how long it takes for the component to be restored. That is, at the very least, one needs a model that describes how the component is restored (a repair probability distribution).
 

In this chapter, we will introduce the additional information, models and metrics required to fully analyze a repairable system.

[[Category:Completed Theoretical Review]]

=Defining Maintenance=

To properly deal with repairable systems, we need to first understand how components in these systems are restored (i.e. the maintenance actions that the components undergo). In general, maintenance is defined as any action that restores failed units to an operational condition or retains non-failed units in an operational state. For repairable systems, maintenance plays a vital role in the life of a system. It affects the system's overall reliability, availability, downtime, cost of operation, etc. Generally, maintenance actions can be divided into three types: corrective maintenance, preventive maintenance and inspections.

===Corrective Maintenance===

Corrective maintenance consists of the action(s) taken to restore a failed system to operational status. This usually involves replacing or repairing the component that is responsible for the failure of the overall system. Corrective maintenance is performed at unpredictable intervals because a component's failure time is not known a priori. The objective of corrective maintenance is to restore the system to satisfactory operation within the shortest possible time. Corrective maintenance is typically carried out in three steps:
 

:• Diagnosis of the problem. The maintenance technician must take time to locate the failed parts or otherwise satisfactorily assess the cause of the system failure. 
:• Repair and/or replacement of faulty component(s). Once the cause of system failure has been determined, action must be taken to address the cause, usually by replacing or repairing the components that caused the system to fail. 
:• Verification of the repair action. Once the components in question have been repaired or replaced, the maintenance technician must verify that the system is again successfully operating. 
 

===Preventive Maintenance===

Preventive maintenance, unlike corrective maintenance, is the practice of replacing components or subsystems before they fail in order to promote continuous system operation. The schedule for preventive maintenance is based on observation of past system behavior, component wear-out mechanisms and knowledge of which components are vital to continued system operation. Cost is always a factor in the scheduling of preventive maintenance. In many circumstances, it is financially more sensible to replace parts or components that have not failed at predetermined intervals rather than to wait for a system failure that may result in a costly disruption in operations. Preventive maintenance scheduling strategies are discussed in more detail later in this chapter.

===Inspections===

Inspections are used in order to uncover hidden failures (also called dormant failures). In general, no maintenance action is performed on the component during an inspection unless the component is found failed, in which case a corrective maintenance action is initiated. However, there might be cases where a partial restoration of the inspected item would be performed during an inspection. For example, when checking the motor oil in a car between scheduled oil changes, one might occasionally add some oil in order to keep it at a constant level. The subject of inspections is discussed in more detail in Chapter 8.

=Downtime Distributions=

Maintenance actions (preventive or corrective) are not instantaneous. There is a time associated with each action (i.e. the amount of time it takes to complete the action). This time is usually referred to as downtime and it is defined as the length of time an item is not operational. There are a number of different factors that can affect the length of downtime, such as the physical characteristics of the system, spare part availability, repair crew availability, human factors, environmental factors, etc. Downtime can be divided into two categories based on these factors:
 
:• Waiting Downtime. This is the time during which the equipment is inoperable but not yet undergoing repair. This could be due to the time it takes for replacement parts to be shipped, administrative processing time, etc. 
:•Active Downtime. This is the time during which the equipment is inoperable and actually undergoing repair. In other words, the active downtime is the time it takes repair personnel to perform a repair or replacement. The length of the active downtime is greatly dependent on human factors, as well as on the design of the equipment. For example, the ease of accessibility of components in a system has a direct effect on the active downtime. 

These downtime definitions are subjective and not necessarily mutually exclusive nor all-inclusive. As an example, consider the time required to diagnose the problem. One may need to diagnose the problem before ordering parts and then wait for the parts to arrive.
 

The influence of a variety of different factors on downtime results in the fact that the time it takes to repair/restore a specific item is not generally constant. That is, the time-to-repair is a random variable, much like the time-to-failure. The statement that it takes on average five hours to repair implies an underlying probabilistic distribution. Distributions that describe the time-to-repair are called repair distributions (or downtime distributions) in order to distinguish them from the failure distributions. However, the methods employed to quantify these distributions are not any different mathematically than the methods employed to quantify failure distributions. The difference is in how they are employed (i.e. the events they describe and metrics used). As an example, when using a life distribution with failure data (i.e. the event modeled was time-to-failure), unreliability provides the probability that the event (failure) will occur by that time, while reliability provides the probability that the event (failure) will not occur. In the case of downtime distributions, the data set consists of times-to-repair, thus what we termed as unreliability now becomes the probability of the event occurring (i.e. repairing the component). Using these definitions, the probability of repairing the component by a given time, <math>t</math> , is also called the component's maintainability.

=Maintainability=
Maintainability is defined as the probability of performing a successful repair action within a given time. In other words, maintainability measures the ease and speed with which a system can be restored to operational status after a failure occurs. For example, if it is said that a particular component has a 90% maintainability in one hour, this means that there is a 90% probability that the component will be repaired within an hour. In maintainability, the random variable is time-to-repair, in the same manner as time-to-failure is the random variable in reliability. As an example, consider the maintainability equation for a system in which the repair times are distributed exponentially. Its maintainability <math>M\left( t \right)</math> is given by:
 

::<math>M\left( t \right)=1-{{e}^{-\mu \cdot t}}</math>
 

Where <math>\mu </math> = repair rate.
 

Note the similarity between this equation and the equation for the reliability of a system with exponentially distributed failure times. However, since the maintainability represents the probability of an event occurring (repairing the system) while the reliability represents the probability of an event not occurring (failure), the maintainability expression is the equivalent of the unreliability expression, <math>(1-R)</math> . Furthermore, the single model parameter <math>\mu </math> is now referred to as the repair rate, which is analogous to the failure rate, <math>\lambda </math> , used in reliability for an exponential distribution.
 

Similarly, the mean of the distribution can be obtained by:

 

::<math>\frac{1}{\mu }=MTTR\text{(mean time to repair)}</math>
 

This now becomes the mean time to repair ( <math>MTTR</math> ) instead of the mean time to failure ( <math>MTTF</math> ).
 

The same concept can be expanded to other distributions. In the case of the Weibull distribution, maintainability, <math>M\left( t \right)</math> , is given by:
 

::<math>M(t)=1-{{e}^{-{{\left( \tfrac{t}{\eta } \right)}^{\beta }}}}</math>

 

While the mean time to repair ( <math>MTTR</math> ) is given by:

 

::<math>MTTR\quad =\eta \cdot \Gamma \left( \frac{1}{\beta }+1 \right)</math>
 

And the Weibull repair rate is given by:
 

::<math>\mu (t)=\frac{\beta }{\eta }{{\left( \frac{t}{\eta } \right)}^{\beta -1}}</math>

 

As a last example, if a lognormal distribution is chosen, then:

 

::<math>M(t)=\mathop{}_{0}^{{{T}^{^{\prime }}}}\frac{1}{{{\sigma }_{{{T}'}}}\sqrt{2\pi }}{{e}^{-\tfrac{1}{2}{{\left( \tfrac{t-\overline{{{T}'}}}{{{\sigma }_{{{T}'}}}} \right)}^{2}}}}dt</math>

 

Where:
 
:• <math>\bar{{T}'}=</math> mean of the natural logarithms of the times-to-repair. 
:• <math>{{\sigma }_{{{T}'}}}=</math> standard deviation of the natural logarithms of the times-to-repair. 
 

It should be clear by now that any distribution can be used, as well as related concepts and methods used in life data analysis. The only difference being that instead of times-to-failure we are using times-to-repair. What one chooses to include in the time-to-repair varies, but can include:
 

#The time it takes to successfully diagnose the cause of the failure. 
#The time it takes to procure or deliver the parts necessary to perform the repair. 
#The time it takes to gain access to the failed part or parts. 
#The time it takes to remove the failed components and replace them with functioning ones. 
#The time involved with bringing the system back to operating status. 
#The time it takes to verify that the system is functioning within specifications. 
#The time associated with closing up a system and returning it to normal operation. 
 

In the interest of being fair and accurate, one should disclose (document) what was and was not included in determining the repair distribution.

=Availability=
If one considers both reliability (probability that the item will not fail) and maintainability (the probability that the item is successfully restored after failure), then an additional metric is needed for the probability that the component/system is operational at a given time, <math>t</math> (i.e. has not failed or it has been restored after failure). This metric is availability. Availability is a performance criterion for repairable systems that accounts for both the reliability and maintainability properties of a component or system. It is defined as the probability that the system is operating properly when it is requested for use. That is, availability is the probability that a system is not failed or undergoing a repair action when it needs to be used. For example, if a lamp has a 99.9% availability, there will be one time out of a thousand that someone needs to use the lamp and finds out that the lamp is not operational either because the lamp is burned out or the lamp is in the process of being replaced. Note that this metric alone tells us nothing about how many times the lamp has been replaced. For all we know, the lamp may be replaced every day or it could have never been replaced at all. Other metrics are still important and needed, such as the lamp's reliability. The next table illustrates the relationship between reliability, maintainability and availability.
 

[[Image:RMAtable.png|center|400px|]]
 

===A Brief Introduction to Renewal Theory===

For a repairable system, the time of operation is not continuous. In other words, its life cycle can be described by a sequence of up and down states. The system operates until it fails, then it is repaired and returned to its original operating state. It will fail again after some random time of operation, get repaired again, and this process of failure and repair will repeat. This is called a renewal process and is defined as a sequence of independent and non-negative random variables. In this case, the random variables are the times-to-failure and the times-to-repair/restore. Each time a unit fails and is restored to working order, a renewal is said to have occurred. This type of renewal process is known as an alternating renewal process because the state of the component alternates between a functioning state and a repair state, as illustrated in the following graphic.
 

[[Image:AlternatingRP.png|center|400px|]]
 

A system's renewal process is determined by the renewal processes of its components. For example, consider a series system of three statistically independent components. Each component has a failure distribution and a repair distribution. Since the components are in series, when one component fails, the entire system fails. The system is then down for as long as the failed component is under repair. Figure "System downtime as a function of three component downtimes. Components A, B, and C are in series" illustrates this.
 

[[Image:AlternatingRP2.png|center|400px|System downtime as a function of three component downtimes. Components A, B, and C are in series.]]

 
One of the main assumptions in renewal theory is that the failed components are replaced with new ones or are repaired so they are as good as new, hence the name renewal. One can make the argument that this is the case for every repair, if you define the system in enough detail. In other words, if the repair of a single circuit board in the system involves the replacement of a single transistor in the offending circuit board, then if the analysis (or RBD) is performed down to the transistor level, the transistor itself gets renewed. In cases where the analysis is done at a higher level, or if the offending component is replaced with a used component, additional steps are required. We will discuss this in later chapters using a restoration factor in the analysis. For more details on renewal theory, interested readers can refer to [[Appendix_B:_References | Elsayed [7]]] and [[Appendix_B:_References | Leemis [17]]].

===Availability Classifications===

The definition of availability is somewhat flexible and is largely based on what types of downtimes one chooses to consider in the analysis. As a result, there are a number of different classifications of availability, such as:
 
:• Instantaneous (or Point) Availability. 
:• Average Up-Time Availability (or Mean Availability). 
:• Steady State Availability. 
:• Inherent Availability. 
:• Achieved Availability. 
:• Operational Availability. 

====Instantaneous or Point Availability, <math>A\left( t \right)</math>====

Instantaneous (or point) availability is the probability that a system (or component) will be operational (up and running) at any random time, t. This is very similar to the reliability function in that it gives a probability that a system will function at the given time, t. Unlike reliability, the instantaneous availability measure incorporates maintainability information. At any given time, t, the system will be operational if the following conditions are met ([[Appendix_B:_References |Elsayed [7]]]):
 

The item functioned properly from <math>0</math> to <math>t</math> with probability <math>R(t)</math> or it functioned properly since the last repair at time u, <math>0<u<t</math> , with probability:
 

::<math>\mathop{}_{0}^{t}R(t-u)m(u)du</math>
 

With <math>m(u)</math> being the renewal density function of the system.
 

Then the point availability is the summation of these two probabilities, or:

 

::<math>A\left( t \right)=R(t)+\mathop{}_{0}^{t}R(t-u)m(u)du(eqn 1)</math>

 

====Average Uptime Availability (or Mean Availability), <math>\overline{A}\left( t \right)</math>====

The mean availability is the proportion of time during a mission or time period that the system is available for use. It represents the mean value of the instantaneous availability function over the period (0, T] and is given by:

 

::<math>\overline{A\left( t \right)}=\frac{1}{t}\mathop{}_{0}^{t}A\left( u \right)du(eqn 2)</math>

 

====Steady State Availability, <math>A(\infty )</math>====

The steady state availability of the system is the limit of the instantaneous availability function as time approaches infinity or:
 

::<math>A(\infty )=\underset{t\to \infty }{\overset{}{\mathop{\lim }}}\,A(t)(eqn 3)</math>

 

Figure "Illustration of point availiablity approaching steady state" also illustrates this graphically.
 

In other words, one can think of the steady state availability as a stabilizing point where the system's availability is a constant value. However, one has to be very careful in using the steady state availability as the sole metric for some systems, especially systems that do not need regular maintenance. A large scale system with repeated repairs, such as a car, will reach a point where it is almost certain that something will break and need repair once a month. However, this state may not be reached until, say, 500,000 miles. Obviously, if I am an operator of rental vehicles and I only keep the vehicles until they reach 50,000 miles, then this value would not be of any use to me. Similarly, if I am an auto maker and only warrant the vehicles to <math>X</math> miles, is knowing the steady state value useful?
 

[[Image:7.2.png|center|400px|Illustration of point availiablity approaching steady state.]]
 

====Inherent Availability, <math>{{A}_{I}}</math>====

Inherent availability is the steady state availability when considering only the corrective downtime of the system.
 
For a single component, this can be computed by:

 

::<math>{{A}_{I}}=\frac{MTTF}{MTTF+MTTR}</math>

 

This gets slightly more complicated for a system. To do this, one needs to look at the mean time between failures, or <math>MTBF</math> , and compute this as follows:

 

::<math>{{A}_{I}}=\frac{MTBF}{MTBF+MTTR}</math>

 

This may look simple. However, one should keep in mind that until the steady state is reached, the <math>MTBF</math> may be a function of time (e.g. a degrading system), thus the above formulation should be used cautiously. Furthermore, it is important to note that the <math>MTBF</math> defined here is different from the <math>MTTF</math> (or more precisely for a repairable system, <math>MTTFF</math> , mean time to first failure).

====Achieved Availability, <math>{{A}_{A}}</math> ====

Achieved availability is very similar to inherent availability with the exception that preventive maintenance (PM) downtimes are also included. Specifically, it is the steady state availability when considering corrective and preventive downtime of the system. It can be computed by looking at the mean time between maintenance actions, <math>MTBM,</math> and the mean maintenance downtime, <math>\overline{M},</math> or:

 

::<math>{{A}_{A}}=\frac{MTBM}{MTBM+\overline{M}}</math>

 

====Operational Availability, <math>{{A}_{o}}</math>====

Operational availability is a measure of the average availability over a period of time and it includes all experienced sources of downtime, such as administrative downtime, logistic downtime, etc.
 
Operational availability is the ratio of the system uptime and total time. Mathematically, it is given by:

 

::<math>{{A}_{o}}=\frac{Uptime}{Operating\text{ }Cycle}</math>
 

Where the operating cycle is the overall time period of operation being investigated and uptime is the total time the system was functioning during the operating cycle.
 

When there is no specified logistic downtime or preventive maintenance, equation above returns the Mean Availability of the system.
The operational availability is the availability that the customer actually experiences. It is essentially the a posteriori availability based on actual events that happened to the system. The previous availability definitions are a priori estimations based on models of the system failure and downtime distributions. In many cases, operational availability cannot be controlled by the manufacturer due to variation in location, resources and other factors that are the sole province of the end user of the product.

===Example 1===

As an example, consider the following scenario. A diesel power generator is supplying electricity at a research site in Antarctica. The personnel are not satisfied with the generator. They estimated that in the past six months, they were without electricity due to generator failure for an accumulated time of 1.5 months.
Therefore, the operational availability of the diesel generator experienced by the personnel of the station is:

 

::<math>{{A}_{o}}=\frac{4.5\text{ months}}{6\text{ months}}=0.75</math>

 

Obviously, this is not satisfactory performance for an electrical generator in such a climate, so alternatives to this source of electricity are investigated. One alternative under consideration is a wind-powered electrical turbine, which the manufacturer claims to have a 99.71% availability. This is much higher than the availability experienced by the crew of the Antarctic research station for the diesel generator. Upon investigation, it was found that the wind-turbine manufacturer estimated the availability based on the following information:
 

Failure Distribution
Exponential, <math>MTTF=2400</math> <math>hr</math>

Repair Distribution
Exponential, <math>MTTR=7</math> <math>hr</math>
 

Based on the above information, one can estimate the mean availability for the wind turbine over a period of six months to be:
 

::<math>\overline{A}={{A}_{I}}=0.9972</math>

 

This availability, however, was obtained solely by considering the claimed failure and repair properties of the wind-turbine. Waiting downtime was not considered in the above calculation. Therefore, this availability measure cannot be compared to the operational availability for the diesel generator since the two availability measurements have different inputs. This form of availability measure is also known as inherent availability. In order to make a meaningful comparison, the inherent availability of the diesel generator needs to be estimated. The diesel generator has an <math>MTTF</math> = 50 days (or 1200 hours) and an <math>MTTR</math> = 3 hours. Thus, an estimate of the mean availability is:
 

::<math>\overline{A}={{A}_{I}}=0.9975</math>

 

Note that the inherent availability of the diesel generator is actually a little bit better than the inherent availability of the wind-turbine! Even though the diesel generator has a higher failure rate, its mean-time-to-repair is much smaller than that of the wind turbine, resulting in a slightly higher inherent availability value. This example illustrates the potentially large differences in the types of availability measurements, as well as their misuse.
In this example, the operational availability is much lower than the inherent availability. This is because the inherent availability does not account for downtime due to administrative time, logistic time, the time required to obtain spare parts or the time it takes for the repair personnel to arrive at the site.

=Preventive Maintenance=
Preventive maintenance (PM) is a schedule of planned maintenance actions aimed at the prevention of breakdowns and failures. The primary goal of preventive maintenance is to prevent the failure of equipment before it actually occurs. It is designed to preserve and enhance equipment reliability by replacing worn components before they actually fail. Preventive maintenance activities include equipment checks, partial or complete overhauls at specified periods, oil changes, lubrication and so on. In addition, workers can record equipment deterioration so they know to replace or repair worn parts before they cause system failure. Recent technological advances in tools for inspection and diagnosis have enabled even more accurate and effective equipment maintenance. The ideal preventive maintenance program would prevent all equipment failure before it occurs.

===Value of Preventive Maintenance===

There are multiple misconceptions about preventive maintenance. One such misconception is that PM is unduly costly. This logic dictates that it would cost more for regularly scheduled downtime and maintenance than it would normally cost to operate equipment until repair is absolutely necessary. This may be true for some components; however, one should compare not only the costs but the long-term benefits and savings associated with preventive maintenance. Without preventive maintenance, for example, costs for lost production time from unscheduled equipment breakdown will be incurred. Also, preventive maintenance will result in savings due to an increase of effective system service life.
 

Long-term benefits of preventive maintenance include:
 
:• Improved system reliability. 
:• Decreased cost of replacement. 
:• Decreased system downtime. 
:• Better spares inventory management. 
 
Long-term effects and cost comparisons usually favor preventive maintenance over performing maintenance actions only when the system fails.

====When Does Preventive Maintenance Make Sense?====

Preventive maintenance is a logical choice if, and only if, the following two conditions are met:
 
:• Condition #1: The component in question has an increasing failure rate. In other words, the failure rate of the component increases with time, implying wear-out. Preventive maintenance of a component that is assumed to have an exponential distribution (which implies a constant failure rate) does not make sense! 
:• Condition #2: The overall cost of the preventive maintenance action must be less than the overall cost of a corrective action. 
 
If both of these conditions are met, then preventive maintenance makes sense. Additionally, based on the costs ratios, an optimum time for such action can be easily computed for a single component. This is detailed in later sections.

====The Fallacy of "Constant Failure Rate" and "Preventive Replacement"====

Even though we alluded to the fact in the last section, it is important to make it explicitly clear that if a component has a constant failure rate (i.e., defined by an exponential distribution), then preventive maintenance of the component will have no effect on the component's failure occurrences. To illustrate this, consider a component with an <math>MTTF</math> = <math>100</math> hours, or <math>\lambda =0.01</math>, and with preventive replacement every 50 hours. The reliability vs. time graph for this case is illustrated in Figure "Reliability vs. time for a single component with an <math>MTTF =100</math> hours, or <math>\lambda =0.01</math>, and with preventive replacement every 50 hours." In this figure, the component is replaced every 50 hours, thereby resetting the component's reliability to one. At first glance, it may seem that the preventive maintenance action is actually maintaining the component at a higher reliability.
 

[[Image:7i2.png|center|400px|Reliability vs. time for a single component with an <math>MTTF =100</math> hours, or <math>\lambda =0.01</math> , and with preventive replacement every 50 hours.]]
 
However, consider the following cases for a single component:
 
 
'''Case 1''': The component's reliability from 0 to 60 hours:
 

:• With preventive maintenance, the component was replaced with a new one at 50 hours so the overall reliability is based on the reliability of the new component for 10 hours, <math>R(t=10)=90.48%</math>, times the reliability of the previous component, <math>R(t=50)=60.65%</math>. The result is <math>R(t=60)=54.88%.</math> 
:• Without preventive maintenance, the reliability would be the reliability of the same component operating to 60 hours, or <math>R(t=60)=54.88%</math>. 
 
'''Case 2''': The component's reliability from 50 to 60 hours:
:• With preventive maintenance, the component was replaced at 50 hours, so this is solely based on the reliability of the new component for a mission of 10 hours, or <math>R(t=10)=90.48%</math>. 
:• Without preventive maintenance, the reliability would be the conditional reliability of the same component operating to 60 hours, having already survived to 50 hours, or <math>{{R}_{C}}(T=60|50)=R(60)/R(50)=90.48%</math> . 
 

As can be seen, both cases-- with and without preventive maintenance-- yield the same results.

===Determining Preventive Replacement Time===

As mentioned earlier, if the component has an increasing failure rate, then a carefully designed preventive maintenance program is beneficial to system availability. Otherwise, the costs of preventive maintenance might actually outweigh the benefits. The objective of a good preventive maintenance program is to either minimize the overall costs (or downtime, etc.) or meet a reliability objective. In order to achieve this, an appropriate interval (time) for scheduled maintenance must be determined. One way to do that is to use the optimum age replacement model, as presented next. The model adheres to the conditions discussed previously:
 
:• The component is exhibiting behavior associated with a wear-out mode. That is, the failure rate of the component is increasing with time. 
:• The cost for planned replacements is significantly less than the cost for unplanned replacements. 
 
Figure "Cost curves for preventive and corrective replacement" shows the Cost Per Unit Time vs. Time plot. In this figure, it can be seen that the corrective replacement costs increase as the replacement interval increases. In other words, the less often you perform a PM action, the higher your corrective costs will be. Obviously, as we let a component operate for longer times, its failure rate increases to a point that it is more likely to fail, thus requiring more corrective actions. The opposite is true for the preventive replacement costs. The longer you wait to perform a PM, the less the costs; if you do PM too often, the costs increase. If we combine both costs, we can see that there is an optimum point that minimizes the costs. In other words, one must strike a balance between the risk (costs) associated with a failure while maximizing the time between PM actions.
 

[[Image:costpertime.png|center|400px|Cost curves for preventive and corrective replacement.]]
 

===Optimum Age Replacement Policy===

To determine the optimum time for such a preventive maintenance action (replacement), we need to mathematically formulate a model that describes the associated costs and risks. In developing the model, it is assumed that if the unit fails before time <math>t</math> , a corrective action will occur and if it does not fail by time <math>t</math> , a preventive action will occur. In other words, the unit is replaced upon failure or after a time of operation, <math>t</math> , whichever occurs first.
Thus, the optimum replacement time can be found by minimizing the cost per unit time, <math>CPUT\left( t \right).</math> <math>CPUT\left( t \right)</math> is given by:
 

::<math>\begin{align}
CPUT\left( t \right)= & \frac{\text{Total Expected Replacement Cost per Cycle}}{\text{Expected Cycle Length}} \\
= & \frac{{{C}_{P}}\cdot R\left( t \right)+{{C}_{U}}\cdot \left[ 1-R\left( t \right) \right]}{\mathop{}_{0}^{t}R\left( s \right)ds}
\end{align}</math>
 

Where:
 
:• <math>R(t)</math> = reliability at time <math>t</math> . 
:• <math>{{C}_{P}}</math> = cost of planned replacement. 
:• <math>{{C}_{U}}</math> = cost of unplanned replacement. 
 
The optimum replacement time interval, <math>t</math> , is the time that minimizes <math>CPUT\left( t \right).</math> This can be found by solving for <math>t</math> such that:
 

::<math>\frac{\partial \left[ CPUT(t) \right]}{\partial t}=0</math>

 

Or by solving for a <math>t</math> that satisfies the following equation:

 

::<math>\frac{\partial \left[ \tfrac{{{C}_{P}}\cdot R\left( t \right)+{{C}_{U}}\cdot \left[ 1-R\left( t \right) \right]}{\mathop{}_{0}^{t}R\left( s \right)ds} \right]}{\partial t}=0</math>
 

Interested readers can refer to [[Appendix_B:_References |Barlow and Hunter [2]]] for more details on this model.
 

===Optimum Replacement Window in BlockSim 8===
The Optimum Replacement window in BlockSim 8 is shown in the figure below.
[[Image:optimum replacement.png|center|800px|Using BlockSim's Optimum Replacement utility to obtain the results in Example 2.]]

==== Available Blocks ====

In BlockSim 7, optimum replacement calculations were performed for individual blocks. The utility in BlockSim 8 allows you to perform calculations either for an individual block or for multiple blocks in a diagram simultaneously. When working with multiple blocks, the calculations can be for individual blocks or for one or more groups of blocks.

If you are working with a diagram instead of with a single block, the Available Blocks area on the left side of the window lists all of the standard blocks (in RBDs) or the events (in fault trees), as well as the switches for any standby containers. The following requirements must be met for an item to be available for inclusion in the optimization calculations:

*Blocks must have a failure distribution.

*Switches must have a failure model assigned. Note that in the standby configuration, the switch is the item that is optimized, not the container or the contained blocks/dependent events.

*The failure model must meet the following requirements.

:*Fixed reliability and exponential distributions are not allowed.

:*Weibull distributions must have beta > 1.

:*Gamma distributions must have k > 1.

:*Loglogistic distributions must have std < 1.

:*For generalized gamma distributions and mixed Weibull distributions, there must be an increasing failure rate within at least one time period. A local optimum can then be found within intervals with an increasing failure rate.

You can select an individual item's check box or drag the block into the table on the right side of the window to include the item in the optimization calculations. You can also select the check box in the Available Blocks header to select all check boxes. To remove items from the optimization calculations, you must clear the check box(es); you cannot drag items out of the table.

For each item that is included in the optimization calculations, you will need to specify the cost for a planned replacement and the cost for an unplanned replacement. This is done by calculating the costs for replacement based on the item settings using equations or simulation and then, if desired, manually entering any additional costs for either type of replacement in the corresponding columns of the table.

====Estimate Costs====
This calculates the costs of planned and unplanned tasks for each item based on its associated URD using the following equations.

*For the cost of planned tasks, here denoted as PM cost:

::<math>\begin{align}
\text{PM Cost}= \left(\text{PM Down Time Rate}+ \text{Block Level Down Time Rate} \right)\cdot \left( \text{MTTPM}+\text{Pool Delay} +\text{Crew Delay} \right) \\
+ \text{Crew Labor Rate} \cdot \text{MTTPM} + \text{Cost per PM} + \text{Cost per Pool} +\text{Cost per Crew}
\end{align}</math>
 

Notice: Only PM tasks based on item age are considered. If there is more than one PM task based on item age, only the first one is considered.
*For the cost of the unplanned task, here denoted as CM cost:
::<math>\begin{align}
\text{CM Cost}= \left(\text{CM Down Time Rate}+ \text{Block Level Down Time Rate} \right)\cdot \left( \text{MTTR}+\text{Pool Delay} +\text{Crew Delay} \right) \\
+ \text{Crew Labor Rate} \cdot \text{MTTR} + \text{Cost per CM} + \text{Cost per Pool} +\text{Cost per Crew} \\
+\text{Block Level Cost per Failure}
\end{align}</math>
 

The results will be used to populate the "Calculated Planned Replacement Cost" and "Calculated Unplanned Replacement Cost" columns.

====Estimate Costs Using Simulation====
This calculates the costs of planned and unplanned tasks for each item based on its associated URD using simulation. In other words, we run simulation for each item alone and estimate its costs.
When you choose this command, a Simulation Settings window is shown, allowing you to specify the simulation settings. Once the simulation settings are specified, you can estimate the costs for each item using simulation.

The results will be used to populate the "Calculated Planned Replacement Cost" and "Calculated Unplanned Replacement Cost" columns.

==== Calculate ====
If you are working with a diagram instead of with a single block, when you click Calculate, you can choose from the following options:
*Calculate the individual optimum replacement time for each item.
*Calculate a common optimum replacement time, which is the most cost-effective time to replace all of the selected items concurrently.
*Calculate clustered optimum replacement times, which allows you to specify a number of times to replace groups of the selected items. For example, if you enter 3 in the Number of clusters field, the software will determine the three best times to replace groups of items such that all of the selected items are replaced at one of the three times.

If you are working with a single block, no choice is necessary.
BlockSim will calculate the optimum replacement time for the items based on their failure characteristics and on the defined costs. This value will be displayed in the Optimum Replacement Time column of the table. In addition, the Cost per Unit Time column will display the estimated cost per unit time for a replacement performed at the calculated optimum replacement time. Multiply the replacement time by the cost per unit time to obtain the cost of replacing the item at the optimum replacement time

====Cost vs. Time Plot====
Choosing this command shows a plot of the results. If you have calculated individual optimum replacement times, the plot will show the cost for each item as a function of time. If you have calculated a common optimum replacement time, the plot will show the common cost as a function of time. If you have calculated clustered optimum replacement times, the plot will show the cost for each cluster as a function of time.

==== Create Maintenance Task(s) at Replacement Time====
This enable you to create a preventive task for one or more of the items. The window that appears allows you to select which items to create tasks for. The preventive tasks created in this way restore the item to as good as new condition and are scheduled at fixed intervals based on item age, equal to the optimum replacement time.

===Example 2===

The failure distribution of a component is described by a 2-parameter Weibull distribution with <math>\beta </math> = 2.5 and <math>\eta </math> = 1000 hours.
 
:• The cost for a corrective replacement is <math>\$5</math> . 
:• The cost for a preventive replacement is <math>\$1</math> . 
 
Estimate the optimum replacement age in order to minimize these costs.

====Solution to Example 2====

Prior to obtaining an optimum replacement interval for this component, the assumptions of the following equation must be checked.
::<math>\begin{align}
CPUT\left( t \right)= & \frac{\text{Total Expected Replacement Cost per Cycle}}{\text{Expected Cycle Length}} \\
= & \frac{{{C}_{P}}\cdot R\left( t \right)+{{C}_{U}}\cdot \left[ 1-R\left( t \right) \right]}{\mathop{}_{0}^{t}R\left( s \right)ds}
\end{align}</math>
 
The component has an increasing failure rate, since it follows a Weibull distribution with <math>\beta </math> greater than 1. Note that if <math>\beta =1</math> , then the component has a constant failure rate and if <math>\beta <1</math> , it has a decreasing failure rate. If either of these cases exist, then preventive replacement is unwise. Furthermore, the cost for preventive replacement is less than the corrective replacement cost. Thus, the conditions for the optimum age replacement policy have been met.
 

Using BlockSim, the failure parameters can be entered in the component's Block Properties window. You can then open the Optimum Replacement window and enter the costs (note that here we have to enter the costs, $1 and $5, in the "Additional Planned Replacement Cost" and "Additional Unplanned Replacement Cost" columns respectively) and compute the optimum time, <math>493.0470</math> . Figure "Using BlockSim's Optimum Replacement utility to obtain the results in Example 2" illustrates this.
 

The figure below shows a plot illustrating the cost per unit time.

[[Image:BS7.6.png|thumb|center|400px|Graph of cost vs. replacement time for Example 2.]]
 

====Discussion on Example 2====

The effect of the corrective/preventive cost ratio on the optimum replacement interval is plotted in Figure "Replacement interval as a function of the corrective/preventive cost ratio". It can be seen that as the cost ratio increases, the optimum replacement interval decreases. This is an expected result because the corrective replacement costs are much greater than the preventive replacement costs. Therefore, it becomes more cost effective to replace the component more frequently before it fails.
 
[[Image:BS7.7.png|thumb|center|400px|Replacement interval as a function of the corrective/preventive cost ratio.]]

=Applying These Principles to Larger Systems=

In this chapter, we explored some of the basic concepts and mathematical formulations involving repairable systems. Most examples/equations were given using a single component and, in some cases, using the exponential distribution for simplicity. In practical applications where one is dealing with large systems composed of many components that fail and get repaired based on different distributions and with additional constraints (such as spare parts, crews, etc.), exact analytical computations become intractable. To solve such systems, one needs to resort to simulation (more specifically, discrete event simulation) to obtain the metrics/results discussed in this section. The next chapter expands on these concepts and introduces these simulation methods.

File:Costpertime.png

2012-03-30T20:55:54Z

Nikki Helms: uploaded a new version of "File:Costpertime.png"

Introduction to Repairable Systems

2012-03-30T20:55:08Z

Nikki Helms: /* Determining Preventive Replacement Time */

{{Template:bsbook|7}}

=Repairable Systems=

In prior chapters, the analysis was focused on determining the reliability of the system (i.e. the probability that the system, subsystem or component will operate successfully by a given time, <math>t</math> .) The prior formulations provided us with the probability of success of the entire system, up to a point in time, without looking at the question: ``What happens if a component fails during that time and is then fixed?'' In dealing with repairable systems, these definitions need to be redefined and adapted to deal with this case of the renewal of systems/components.
 

Repairable systems receive maintenance actions that restore/renew system components when they fail. These actions change the overall makeup of the system. These actions must now be taken into consideration when assessing the behavior of the system because the age of the system components is no longer uniform nor is the time of operation of the system continuous.
 

In attempting to understand the system behavior, additional information and models are now needed for each system component. Our primary input in the prior chapters was a model that described how the component failed (its failure probability distribution). When dealing with components that are repaired, one also needs to know how long it takes for the component to be restored. That is, at the very least, one needs a model that describes how the component is restored (a repair probability distribution).
 

In this chapter, we will introduce the additional information, models and metrics required to fully analyze a repairable system.

[[Category:Completed Theoretical Review]]

=Defining Maintenance=

To properly deal with repairable systems, we need to first understand how components in these systems are restored (i.e. the maintenance actions that the components undergo). In general, maintenance is defined as any action that restores failed units to an operational condition or retains non-failed units in an operational state. For repairable systems, maintenance plays a vital role in the life of a system. It affects the system's overall reliability, availability, downtime, cost of operation, etc. Generally, maintenance actions can be divided into three types: corrective maintenance, preventive maintenance and inspections.

===Corrective Maintenance===

Corrective maintenance consists of the action(s) taken to restore a failed system to operational status. This usually involves replacing or repairing the component that is responsible for the failure of the overall system. Corrective maintenance is performed at unpredictable intervals because a component's failure time is not known a priori. The objective of corrective maintenance is to restore the system to satisfactory operation within the shortest possible time. Corrective maintenance is typically carried out in three steps:
 

:• Diagnosis of the problem. The maintenance technician must take time to locate the failed parts or otherwise satisfactorily assess the cause of the system failure. 
:• Repair and/or replacement of faulty component(s). Once the cause of system failure has been determined, action must be taken to address the cause, usually by replacing or repairing the components that caused the system to fail. 
:• Verification of the repair action. Once the components in question have been repaired or replaced, the maintenance technician must verify that the system is again successfully operating. 
 

===Preventive Maintenance===

Preventive maintenance, unlike corrective maintenance, is the practice of replacing components or subsystems before they fail in order to promote continuous system operation. The schedule for preventive maintenance is based on observation of past system behavior, component wear-out mechanisms and knowledge of which components are vital to continued system operation. Cost is always a factor in the scheduling of preventive maintenance. In many circumstances, it is financially more sensible to replace parts or components that have not failed at predetermined intervals rather than to wait for a system failure that may result in a costly disruption in operations. Preventive maintenance scheduling strategies are discussed in more detail later in this chapter.

===Inspections===

Inspections are used in order to uncover hidden failures (also called dormant failures). In general, no maintenance action is performed on the component during an inspection unless the component is found failed, in which case a corrective maintenance action is initiated. However, there might be cases where a partial restoration of the inspected item would be performed during an inspection. For example, when checking the motor oil in a car between scheduled oil changes, one might occasionally add some oil in order to keep it at a constant level. The subject of inspections is discussed in more detail in Chapter 8.

=Downtime Distributions=

Maintenance actions (preventive or corrective) are not instantaneous. There is a time associated with each action (i.e. the amount of time it takes to complete the action). This time is usually referred to as downtime and it is defined as the length of time an item is not operational. There are a number of different factors that can affect the length of downtime, such as the physical characteristics of the system, spare part availability, repair crew availability, human factors, environmental factors, etc. Downtime can be divided into two categories based on these factors:
 
:• Waiting Downtime. This is the time during which the equipment is inoperable but not yet undergoing repair. This could be due to the time it takes for replacement parts to be shipped, administrative processing time, etc. 
:•Active Downtime. This is the time during which the equipment is inoperable and actually undergoing repair. In other words, the active downtime is the time it takes repair personnel to perform a repair or replacement. The length of the active downtime is greatly dependent on human factors, as well as on the design of the equipment. For example, the ease of accessibility of components in a system has a direct effect on the active downtime. 

These downtime definitions are subjective and not necessarily mutually exclusive nor all-inclusive. As an example, consider the time required to diagnose the problem. One may need to diagnose the problem before ordering parts and then wait for the parts to arrive.
 

The influence of a variety of different factors on downtime results in the fact that the time it takes to repair/restore a specific item is not generally constant. That is, the time-to-repair is a random variable, much like the time-to-failure. The statement that it takes on average five hours to repair implies an underlying probabilistic distribution. Distributions that describe the time-to-repair are called repair distributions (or downtime distributions) in order to distinguish them from the failure distributions. However, the methods employed to quantify these distributions are not any different mathematically than the methods employed to quantify failure distributions. The difference is in how they are employed (i.e. the events they describe and metrics used). As an example, when using a life distribution with failure data (i.e. the event modeled was time-to-failure), unreliability provides the probability that the event (failure) will occur by that time, while reliability provides the probability that the event (failure) will not occur. In the case of downtime distributions, the data set consists of times-to-repair, thus what we termed as unreliability now becomes the probability of the event occurring (i.e. repairing the component). Using these definitions, the probability of repairing the component by a given time, <math>t</math> , is also called the component's maintainability.

=Maintainability=
Maintainability is defined as the probability of performing a successful repair action within a given time. In other words, maintainability measures the ease and speed with which a system can be restored to operational status after a failure occurs. For example, if it is said that a particular component has a 90% maintainability in one hour, this means that there is a 90% probability that the component will be repaired within an hour. In maintainability, the random variable is time-to-repair, in the same manner as time-to-failure is the random variable in reliability. As an example, consider the maintainability equation for a system in which the repair times are distributed exponentially. Its maintainability <math>M\left( t \right)</math> is given by:
 

::<math>M\left( t \right)=1-{{e}^{-\mu \cdot t}}</math>
 

Where <math>\mu </math> = repair rate.
 

Note the similarity between this equation and the equation for the reliability of a system with exponentially distributed failure times. However, since the maintainability represents the probability of an event occurring (repairing the system) while the reliability represents the probability of an event not occurring (failure), the maintainability expression is the equivalent of the unreliability expression, <math>(1-R)</math> . Furthermore, the single model parameter <math>\mu </math> is now referred to as the repair rate, which is analogous to the failure rate, <math>\lambda </math> , used in reliability for an exponential distribution.
 

Similarly, the mean of the distribution can be obtained by:

 

::<math>\frac{1}{\mu }=MTTR\text{(mean time to repair)}</math>
 

This now becomes the mean time to repair ( <math>MTTR</math> ) instead of the mean time to failure ( <math>MTTF</math> ).
 

The same concept can be expanded to other distributions. In the case of the Weibull distribution, maintainability, <math>M\left( t \right)</math> , is given by:
 

::<math>M(t)=1-{{e}^{-{{\left( \tfrac{t}{\eta } \right)}^{\beta }}}}</math>

 

While the mean time to repair ( <math>MTTR</math> ) is given by:

 

::<math>MTTR\quad =\eta \cdot \Gamma \left( \frac{1}{\beta }+1 \right)</math>
 

And the Weibull repair rate is given by:
 

::<math>\mu (t)=\frac{\beta }{\eta }{{\left( \frac{t}{\eta } \right)}^{\beta -1}}</math>

 

As a last example, if a lognormal distribution is chosen, then:

 

::<math>M(t)=\mathop{}_{0}^{{{T}^{^{\prime }}}}\frac{1}{{{\sigma }_{{{T}'}}}\sqrt{2\pi }}{{e}^{-\tfrac{1}{2}{{\left( \tfrac{t-\overline{{{T}'}}}{{{\sigma }_{{{T}'}}}} \right)}^{2}}}}dt</math>

 

Where:
 
:• <math>\bar{{T}'}=</math> mean of the natural logarithms of the times-to-repair. 
:• <math>{{\sigma }_{{{T}'}}}=</math> standard deviation of the natural logarithms of the times-to-repair. 
 

It should be clear by now that any distribution can be used, as well as related concepts and methods used in life data analysis. The only difference being that instead of times-to-failure we are using times-to-repair. What one chooses to include in the time-to-repair varies, but can include:
 

#The time it takes to successfully diagnose the cause of the failure. 
#The time it takes to procure or deliver the parts necessary to perform the repair. 
#The time it takes to gain access to the failed part or parts. 
#The time it takes to remove the failed components and replace them with functioning ones. 
#The time involved with bringing the system back to operating status. 
#The time it takes to verify that the system is functioning within specifications. 
#The time associated with closing up a system and returning it to normal operation. 
 

In the interest of being fair and accurate, one should disclose (document) what was and was not included in determining the repair distribution.

=Availability=
If one considers both reliability (probability that the item will not fail) and maintainability (the probability that the item is successfully restored after failure), then an additional metric is needed for the probability that the component/system is operational at a given time, <math>t</math> (i.e. has not failed or it has been restored after failure). This metric is availability. Availability is a performance criterion for repairable systems that accounts for both the reliability and maintainability properties of a component or system. It is defined as the probability that the system is operating properly when it is requested for use. That is, availability is the probability that a system is not failed or undergoing a repair action when it needs to be used. For example, if a lamp has a 99.9% availability, there will be one time out of a thousand that someone needs to use the lamp and finds out that the lamp is not operational either because the lamp is burned out or the lamp is in the process of being replaced. Note that this metric alone tells us nothing about how many times the lamp has been replaced. For all we know, the lamp may be replaced every day or it could have never been replaced at all. Other metrics are still important and needed, such as the lamp's reliability. The next table illustrates the relationship between reliability, maintainability and availability.
 

[[Image:RMAtable.png|center|400px|]]
 

===A Brief Introduction to Renewal Theory===

For a repairable system, the time of operation is not continuous. In other words, its life cycle can be described by a sequence of up and down states. The system operates until it fails, then it is repaired and returned to its original operating state. It will fail again after some random time of operation, get repaired again, and this process of failure and repair will repeat. This is called a renewal process and is defined as a sequence of independent and non-negative random variables. In this case, the random variables are the times-to-failure and the times-to-repair/restore. Each time a unit fails and is restored to working order, a renewal is said to have occurred. This type of renewal process is known as an alternating renewal process because the state of the component alternates between a functioning state and a repair state, as illustrated in the following graphic.
 

[[Image:AlternatingRP.png|center|400px|]]
 

A system's renewal process is determined by the renewal processes of its components. For example, consider a series system of three statistically independent components. Each component has a failure distribution and a repair distribution. Since the components are in series, when one component fails, the entire system fails. The system is then down for as long as the failed component is under repair. Figure "System downtime as a function of three component downtimes. Components A, B, and C are in series" illustrates this.
 

[[Image:AlternatingRP2.png|center|400px|System downtime as a function of three component downtimes. Components A, B, and C are in series.]]

 
One of the main assumptions in renewal theory is that the failed components are replaced with new ones or are repaired so they are as good as new, hence the name renewal. One can make the argument that this is the case for every repair, if you define the system in enough detail. In other words, if the repair of a single circuit board in the system involves the replacement of a single transistor in the offending circuit board, then if the analysis (or RBD) is performed down to the transistor level, the transistor itself gets renewed. In cases where the analysis is done at a higher level, or if the offending component is replaced with a used component, additional steps are required. We will discuss this in later chapters using a restoration factor in the analysis. For more details on renewal theory, interested readers can refer to [[Appendix_B:_References | Elsayed [7]]] and [[Appendix_B:_References | Leemis [17]]].

===Availability Classifications===

The definition of availability is somewhat flexible and is largely based on what types of downtimes one chooses to consider in the analysis. As a result, there are a number of different classifications of availability, such as:
 
:• Instantaneous (or Point) Availability. 
:• Average Up-Time Availability (or Mean Availability). 
:• Steady State Availability. 
:• Inherent Availability. 
:• Achieved Availability. 
:• Operational Availability. 

====Instantaneous or Point Availability, <math>A\left( t \right)</math>====

Instantaneous (or point) availability is the probability that a system (or component) will be operational (up and running) at any random time, t. This is very similar to the reliability function in that it gives a probability that a system will function at the given time, t. Unlike reliability, the instantaneous availability measure incorporates maintainability information. At any given time, t, the system will be operational if the following conditions are met ([[Appendix_B:_References |Elsayed [7]]]):
 

The item functioned properly from <math>0</math> to <math>t</math> with probability <math>R(t)</math> or it functioned properly since the last repair at time u, <math>0<u<t</math> , with probability:
 

::<math>\mathop{}_{0}^{t}R(t-u)m(u)du</math>
 

With <math>m(u)</math> being the renewal density function of the system.
 

Then the point availability is the summation of these two probabilities, or:

 

::<math>A\left( t \right)=R(t)+\mathop{}_{0}^{t}R(t-u)m(u)du(eqn 1)</math>

 

====Average Uptime Availability (or Mean Availability), <math>\overline{A}\left( t \right)</math>====

The mean availability is the proportion of time during a mission or time period that the system is available for use. It represents the mean value of the instantaneous availability function over the period (0, T] and is given by:

 

::<math>\overline{A\left( t \right)}=\frac{1}{t}\mathop{}_{0}^{t}A\left( u \right)du(eqn 2)</math>

 

====Steady State Availability, <math>A(\infty )</math>====

The steady state availability of the system is the limit of the instantaneous availability function as time approaches infinity or:
 

::<math>A(\infty )=\underset{t\to \infty }{\overset{}{\mathop{\lim }}}\,A(t)(eqn 3)</math>

 

Figure "Illustration of point availiablity approaching steady state" also illustrates this graphically.
 

In other words, one can think of the steady state availability as a stabilizing point where the system's availability is a constant value. However, one has to be very careful in using the steady state availability as the sole metric for some systems, especially systems that do not need regular maintenance. A large scale system with repeated repairs, such as a car, will reach a point where it is almost certain that something will break and need repair once a month. However, this state may not be reached until, say, 500,000 miles. Obviously, if I am an operator of rental vehicles and I only keep the vehicles until they reach 50,000 miles, then this value would not be of any use to me. Similarly, if I am an auto maker and only warrant the vehicles to <math>X</math> miles, is knowing the steady state value useful?
 

[[Image:7.2.png|center|400px|Illustration of point availiablity approaching steady state.]]
 

====Inherent Availability, <math>{{A}_{I}}</math>====

Inherent availability is the steady state availability when considering only the corrective downtime of the system.
 
For a single component, this can be computed by:

 

::<math>{{A}_{I}}=\frac{MTTF}{MTTF+MTTR}</math>

 

This gets slightly more complicated for a system. To do this, one needs to look at the mean time between failures, or <math>MTBF</math> , and compute this as follows:

 

::<math>{{A}_{I}}=\frac{MTBF}{MTBF+MTTR}</math>

 

This may look simple. However, one should keep in mind that until the steady state is reached, the <math>MTBF</math> may be a function of time (e.g. a degrading system), thus the above formulation should be used cautiously. Furthermore, it is important to note that the <math>MTBF</math> defined here is different from the <math>MTTF</math> (or more precisely for a repairable system, <math>MTTFF</math> , mean time to first failure).

====Achieved Availability, <math>{{A}_{A}}</math> ====

Achieved availability is very similar to inherent availability with the exception that preventive maintenance (PM) downtimes are also included. Specifically, it is the steady state availability when considering corrective and preventive downtime of the system. It can be computed by looking at the mean time between maintenance actions, <math>MTBM,</math> and the mean maintenance downtime, <math>\overline{M},</math> or:

 

::<math>{{A}_{A}}=\frac{MTBM}{MTBM+\overline{M}}</math>

 

====Operational Availability, <math>{{A}_{o}}</math>====

Operational availability is a measure of the average availability over a period of time and it includes all experienced sources of downtime, such as administrative downtime, logistic downtime, etc.
 
Operational availability is the ratio of the system uptime and total time. Mathematically, it is given by:

 

::<math>{{A}_{o}}=\frac{Uptime}{Operating\text{ }Cycle}</math>
 

Where the operating cycle is the overall time period of operation being investigated and uptime is the total time the system was functioning during the operating cycle.
 

When there is no specified logistic downtime or preventive maintenance, equation above returns the Mean Availability of the system.
The operational availability is the availability that the customer actually experiences. It is essentially the a posteriori availability based on actual events that happened to the system. The previous availability definitions are a priori estimations based on models of the system failure and downtime distributions. In many cases, operational availability cannot be controlled by the manufacturer due to variation in location, resources and other factors that are the sole province of the end user of the product.

===Example 1===

As an example, consider the following scenario. A diesel power generator is supplying electricity at a research site in Antarctica. The personnel are not satisfied with the generator. They estimated that in the past six months, they were without electricity due to generator failure for an accumulated time of 1.5 months.
Therefore, the operational availability of the diesel generator experienced by the personnel of the station is:

 

::<math>{{A}_{o}}=\frac{4.5\text{ months}}{6\text{ months}}=0.75</math>

 

Obviously, this is not satisfactory performance for an electrical generator in such a climate, so alternatives to this source of electricity are investigated. One alternative under consideration is a wind-powered electrical turbine, which the manufacturer claims to have a 99.71% availability. This is much higher than the availability experienced by the crew of the Antarctic research station for the diesel generator. Upon investigation, it was found that the wind-turbine manufacturer estimated the availability based on the following information:
 

Failure Distribution
Exponential, <math>MTTF=2400</math> <math>hr</math>

Repair Distribution
Exponential, <math>MTTR=7</math> <math>hr</math>
 

Based on the above information, one can estimate the mean availability for the wind turbine over a period of six months to be:
 

::<math>\overline{A}={{A}_{I}}=0.9972</math>

 

This availability, however, was obtained solely by considering the claimed failure and repair properties of the wind-turbine. Waiting downtime was not considered in the above calculation. Therefore, this availability measure cannot be compared to the operational availability for the diesel generator since the two availability measurements have different inputs. This form of availability measure is also known as inherent availability. In order to make a meaningful comparison, the inherent availability of the diesel generator needs to be estimated. The diesel generator has an <math>MTTF</math> = 50 days (or 1200 hours) and an <math>MTTR</math> = 3 hours. Thus, an estimate of the mean availability is:
 

::<math>\overline{A}={{A}_{I}}=0.9975</math>

 

Note that the inherent availability of the diesel generator is actually a little bit better than the inherent availability of the wind-turbine! Even though the diesel generator has a higher failure rate, its mean-time-to-repair is much smaller than that of the wind turbine, resulting in a slightly higher inherent availability value. This example illustrates the potentially large differences in the types of availability measurements, as well as their misuse.
In this example, the operational availability is much lower than the inherent availability. This is because the inherent availability does not account for downtime due to administrative time, logistic time, the time required to obtain spare parts or the time it takes for the repair personnel to arrive at the site.

=Preventive Maintenance=
Preventive maintenance (PM) is a schedule of planned maintenance actions aimed at the prevention of breakdowns and failures. The primary goal of preventive maintenance is to prevent the failure of equipment before it actually occurs. It is designed to preserve and enhance equipment reliability by replacing worn components before they actually fail. Preventive maintenance activities include equipment checks, partial or complete overhauls at specified periods, oil changes, lubrication and so on. In addition, workers can record equipment deterioration so they know to replace or repair worn parts before they cause system failure. Recent technological advances in tools for inspection and diagnosis have enabled even more accurate and effective equipment maintenance. The ideal preventive maintenance program would prevent all equipment failure before it occurs.

===Value of Preventive Maintenance===

There are multiple misconceptions about preventive maintenance. One such misconception is that PM is unduly costly. This logic dictates that it would cost more for regularly scheduled downtime and maintenance than it would normally cost to operate equipment until repair is absolutely necessary. This may be true for some components; however, one should compare not only the costs but the long-term benefits and savings associated with preventive maintenance. Without preventive maintenance, for example, costs for lost production time from unscheduled equipment breakdown will be incurred. Also, preventive maintenance will result in savings due to an increase of effective system service life.
 

Long-term benefits of preventive maintenance include:
 
:• Improved system reliability. 
:• Decreased cost of replacement. 
:• Decreased system downtime. 
:• Better spares inventory management. 
 
Long-term effects and cost comparisons usually favor preventive maintenance over performing maintenance actions only when the system fails.

====When Does Preventive Maintenance Make Sense?====

Preventive maintenance is a logical choice if, and only if, the following two conditions are met:
 
:• Condition #1: The component in question has an increasing failure rate. In other words, the failure rate of the component increases with time, implying wear-out. Preventive maintenance of a component that is assumed to have an exponential distribution (which implies a constant failure rate) does not make sense! 
:• Condition #2: The overall cost of the preventive maintenance action must be less than the overall cost of a corrective action. 
 
If both of these conditions are met, then preventive maintenance makes sense. Additionally, based on the costs ratios, an optimum time for such action can be easily computed for a single component. This is detailed in later sections.

====The Fallacy of "Constant Failure Rate" and "Preventive Replacement"====

Even though we alluded to the fact in the last section, it is important to make it explicitly clear that if a component has a constant failure rate (i.e., defined by an exponential distribution), then preventive maintenance of the component will have no effect on the component's failure occurrences. To illustrate this, consider a component with an <math>MTTF</math> = <math>100</math> hours, or <math>\lambda =0.01</math>, and with preventive replacement every 50 hours. The reliability vs. time graph for this case is illustrated in Figure "Reliability vs. time for a single component with an <math>MTTF =100</math> hours, or <math>\lambda =0.01</math>, and with preventive replacement every 50 hours." In this figure, the component is replaced every 50 hours, thereby resetting the component's reliability to one. At first glance, it may seem that the preventive maintenance action is actually maintaining the component at a higher reliability.
 

[[Image:7i2.png|center|400px|Reliability vs. time for a single component with an <math>MTTF =100</math> hours, or <math>\lambda =0.01</math> , and with preventive replacement every 50 hours.]]
 
However, consider the following cases for a single component:
 
 
'''Case 1''': The component's reliability from 0 to 60 hours:
 

:• With preventive maintenance, the component was replaced with a new one at 50 hours so the overall reliability is based on the reliability of the new component for 10 hours, <math>R(t=10)=90.48%</math>, times the reliability of the previous component, <math>R(t=50)=60.65%</math>. The result is <math>R(t=60)=54.88%.</math> 
:• Without preventive maintenance, the reliability would be the reliability of the same component operating to 60 hours, or <math>R(t=60)=54.88%</math>. 
 
'''Case 2''': The component's reliability from 50 to 60 hours:
:• With preventive maintenance, the component was replaced at 50 hours, so this is solely based on the reliability of the new component for a mission of 10 hours, or <math>R(t=10)=90.48%</math>. 
:• Without preventive maintenance, the reliability would be the conditional reliability of the same component operating to 60 hours, having already survived to 50 hours, or <math>{{R}_{C}}(T=60|50)=R(60)/R(50)=90.48%</math> . 
 

As can be seen, both cases-- with and without preventive maintenance-- yield the same results.

===Determining Preventive Replacement Time===

As mentioned earlier, if the component has an increasing failure rate, then a carefully designed preventive maintenance program is beneficial to system availability. Otherwise, the costs of preventive maintenance might actually outweigh the benefits. The objective of a good preventive maintenance program is to either minimize the overall costs (or downtime, etc.) or meet a reliability objective. In order to achieve this, an appropriate interval (time) for scheduled maintenance must be determined. One way to do that is to use the optimum age replacement model, as presented next. The model adheres to the conditions discussed previously:
 
:• The component is exhibiting behavior associated with a wear-out mode. That is, the failure rate of the component is increasing with time. 
:• The cost for planned replacements is significantly less than the cost for unplanned replacements. 
 
Figure "Cost curves for preventive and corrective replacement" shows the Cost Per Unit Time vs. Time plot. In this figure, it can be seen that the corrective replacement costs increase as the replacement interval increases. In other words, the less often you perform a PM action, the higher your corrective costs will be. Obviously, as we let a component operate for longer times, its failure rate increases to a point that it is more likely to fail, thus requiring more corrective actions. The opposite is true for the preventive replacement costs. The longer you wait to perform a PM, the less the costs; if you do PM too often, the costs increase. If we combine both costs, we can see that there is an optimum point that minimizes the costs. In other words, one must strike a balance between the risk (costs) associated with a failure while maximizing the time between PM actions.
 

[[Image:costpertime.png|center|400px|Cost curves for preventive and corrective replacement.]]
 

===Optimum Age Replacement Policy===

To determine the optimum time for such a preventive maintenance action (replacement), we need to mathematically formulate a model that describes the associated costs and risks. In developing the model, it is assumed that if the unit fails before time <math>t</math> , a corrective action will occur and if it does not fail by time <math>t</math> , a preventive action will occur. In other words, the unit is replaced upon failure or after a time of operation, <math>t</math> , whichever occurs first.
Thus, the optimum replacement time can be found by minimizing the cost per unit time, <math>CPUT\left( t \right).</math> <math>CPUT\left( t \right)</math> is given by:
 

::<math>\begin{align}
CPUT\left( t \right)= & \frac{\text{Total Expected Replacement Cost per Cycle}}{\text{Expected Cycle Length}} \\
= & \frac{{{C}_{P}}\cdot R\left( t \right)+{{C}_{U}}\cdot \left[ 1-R\left( t \right) \right]}{\mathop{}_{0}^{t}R\left( s \right)ds}
\end{align}</math>
 

Where:
 
:• <math>R(t)</math> = reliability at time <math>t</math> . 
:• <math>{{C}_{P}}</math> = cost of planned replacement. 
:• <math>{{C}_{U}}</math> = cost of unplanned replacement. 
 
The optimum replacement time interval, <math>t</math> , is the time that minimizes <math>CPUT\left( t \right).</math> This can be found by solving for <math>t</math> such that:
 

::<math>\frac{\partial \left[ CPUT(t) \right]}{\partial t}=0</math>

 

Or by solving for a <math>t</math> that satisfies the following equation:

 

::<math>\frac{\partial \left[ \tfrac{{{C}_{P}}\cdot R\left( t \right)+{{C}_{U}}\cdot \left[ 1-R\left( t \right) \right]}{\mathop{}_{0}^{t}R\left( s \right)ds} \right]}{\partial t}=0</math>
 

Interested readers can refer to [[Appendix_B:_References |Barlow and Hunter [2]]] for more details on this model.
 

===Optimum Replacement Window in BlockSim 8===
The Optimum Replacement window in BlockSim 8 is shown in the figure below.
[[Image:optimum replacement.png|thumb|center|800px|Using BlockSim's Optimum Replacement utility to obtain the results in Example 2.]]

==== Available Blocks ====

In BlockSim 7, optimum replacement calculations were performed for individual blocks. The utility in BlockSim 8 allows you to perform calculations either for an individual block or for multiple blocks in a diagram simultaneously. When working with multiple blocks, the calculations can be for individual blocks or for one or more groups of blocks.

If you are working with a diagram instead of with a single block, the Available Blocks area on the left side of the window lists all of the standard blocks (in RBDs) or the events (in fault trees), as well as the switches for any standby containers. The following requirements must be met for an item to be available for inclusion in the optimization calculations:

*Blocks must have a failure distribution.

*Switches must have a failure model assigned. Note that in the standby configuration, the switch is the item that is optimized, not the container or the contained blocks/dependent events.

*The failure model must meet the following requirements.

:*Fixed reliability and exponential distributions are not allowed.

:*Weibull distributions must have beta > 1.

:*Gamma distributions must have k > 1.

:*Loglogistic distributions must have std < 1.

:*For generalized gamma distributions and mixed Weibull distributions, there must be an increasing failure rate within at least one time period. A local optimum can then be found within intervals with an increasing failure rate.

You can select an individual item's check box or drag the block into the table on the right side of the window to include the item in the optimization calculations. You can also select the check box in the Available Blocks header to select all check boxes. To remove items from the optimization calculations, you must clear the check box(es); you cannot drag items out of the table.

For each item that is included in the optimization calculations, you will need to specify the cost for a planned replacement and the cost for an unplanned replacement. This is done by calculating the costs for replacement based on the item settings using equations or simulation and then, if desired, manually entering any additional costs for either type of replacement in the corresponding columns of the table.

====Estimate Costs====
This calculates the costs of planned and unplanned tasks for each item based on its associated URD using the following equations.

*For the cost of planned tasks, here denoted as PM cost:

::<math>\begin{align}
\text{PM Cost}= \left(\text{PM Down Time Rate}+ \text{Block Level Down Time Rate} \right)\cdot \left( \text{MTTPM}+\text{Pool Delay} +\text{Crew Delay} \right) \\
+ \text{Crew Labor Rate} \cdot \text{MTTPM} + \text{Cost per PM} + \text{Cost per Pool} +\text{Cost per Crew}
\end{align}</math>
 

Notice: Only PM tasks based on item age are considered. If there is more than one PM task based on item age, only the first one is considered.
*For the cost of the unplanned task, here denoted as CM cost:
::<math>\begin{align}
\text{CM Cost}= \left(\text{CM Down Time Rate}+ \text{Block Level Down Time Rate} \right)\cdot \left( \text{MTTR}+\text{Pool Delay} +\text{Crew Delay} \right) \\
+ \text{Crew Labor Rate} \cdot \text{MTTR} + \text{Cost per CM} + \text{Cost per Pool} +\text{Cost per Crew} \\
+\text{Block Level Cost per Failure}
\end{align}</math>
 

The results will be used to populate the "Calculated Planned Replacement Cost" and "Calculated Unplanned Replacement Cost" columns.

====Estimate Costs Using Simulation====
This calculates the costs of planned and unplanned tasks for each item based on its associated URD using simulation. In other words, we run simulation for each item alone and estimate its costs.
When you choose this command, a Simulation Settings window is shown, allowing you to specify the simulation settings. Once the simulation settings are specified, you can estimate the costs for each item using simulation.

The results will be used to populate the "Calculated Planned Replacement Cost" and "Calculated Unplanned Replacement Cost" columns.

==== Calculate ====
If you are working with a diagram instead of with a single block, when you click Calculate, you can choose from the following options:
*Calculate the individual optimum replacement time for each item.
*Calculate a common optimum replacement time, which is the most cost-effective time to replace all of the selected items concurrently.
*Calculate clustered optimum replacement times, which allows you to specify a number of times to replace groups of the selected items. For example, if you enter 3 in the Number of clusters field, the software will determine the three best times to replace groups of items such that all of the selected items are replaced at one of the three times.

If you are working with a single block, no choice is necessary.
BlockSim will calculate the optimum replacement time for the items based on their failure characteristics and on the defined costs. This value will be displayed in the Optimum Replacement Time column of the table. In addition, the Cost per Unit Time column will display the estimated cost per unit time for a replacement performed at the calculated optimum replacement time. Multiply the replacement time by the cost per unit time to obtain the cost of replacing the item at the optimum replacement time

====Cost vs. Time Plot====
Choosing this command shows a plot of the results. If you have calculated individual optimum replacement times, the plot will show the cost for each item as a function of time. If you have calculated a common optimum replacement time, the plot will show the common cost as a function of time. If you have calculated clustered optimum replacement times, the plot will show the cost for each cluster as a function of time.

==== Create Maintenance Task(s) at Replacement Time====
This enable you to create a preventive task for one or more of the items. The window that appears allows you to select which items to create tasks for. The preventive tasks created in this way restore the item to as good as new condition and are scheduled at fixed intervals based on item age, equal to the optimum replacement time.

===Example 2===

The failure distribution of a component is described by a 2-parameter Weibull distribution with <math>\beta </math> = 2.5 and <math>\eta </math> = 1000 hours.
 
:• The cost for a corrective replacement is <math>\$5</math> . 
:• The cost for a preventive replacement is <math>\$1</math> . 
 
Estimate the optimum replacement age in order to minimize these costs.

====Solution to Example 2====

Prior to obtaining an optimum replacement interval for this component, the assumptions of the following equation must be checked.
::<math>\begin{align}
CPUT\left( t \right)= & \frac{\text{Total Expected Replacement Cost per Cycle}}{\text{Expected Cycle Length}} \\
= & \frac{{{C}_{P}}\cdot R\left( t \right)+{{C}_{U}}\cdot \left[ 1-R\left( t \right) \right]}{\mathop{}_{0}^{t}R\left( s \right)ds}
\end{align}</math>
 
The component has an increasing failure rate, since it follows a Weibull distribution with <math>\beta </math> greater than 1. Note that if <math>\beta =1</math> , then the component has a constant failure rate and if <math>\beta <1</math> , it has a decreasing failure rate. If either of these cases exist, then preventive replacement is unwise. Furthermore, the cost for preventive replacement is less than the corrective replacement cost. Thus, the conditions for the optimum age replacement policy have been met.
 

Using BlockSim, the failure parameters can be entered in the component's Block Properties window. You can then open the Optimum Replacement window and enter the costs (note that here we have to enter the costs, $1 and $5, in the "Additional Planned Replacement Cost" and "Additional Unplanned Replacement Cost" columns respectively) and compute the optimum time, <math>493.0470</math> . Figure "Using BlockSim's Optimum Replacement utility to obtain the results in Example 2" illustrates this.
 

The figure below shows a plot illustrating the cost per unit time.

[[Image:BS7.6.png|thumb|center|400px|Graph of cost vs. replacement time for Example 2.]]
 

====Discussion on Example 2====

The effect of the corrective/preventive cost ratio on the optimum replacement interval is plotted in Figure "Replacement interval as a function of the corrective/preventive cost ratio". It can be seen that as the cost ratio increases, the optimum replacement interval decreases. This is an expected result because the corrective replacement costs are much greater than the preventive replacement costs. Therefore, it becomes more cost effective to replace the component more frequently before it fails.
 
[[Image:BS7.7.png|thumb|center|400px|Replacement interval as a function of the corrective/preventive cost ratio.]]

=Applying These Principles to Larger Systems=

In this chapter, we explored some of the basic concepts and mathematical formulations involving repairable systems. Most examples/equations were given using a single component and, in some cases, using the exponential distribution for simplicity. In practical applications where one is dealing with large systems composed of many components that fail and get repaired based on different distributions and with additional constraints (such as spare parts, crews, etc.), exact analytical computations become intractable. To solve such systems, one needs to resort to simulation (more specifically, discrete event simulation) to obtain the metrics/results discussed in this section. The next chapter expands on these concepts and introduces these simulation methods.