ReliaWiki - User contributions [en]

Crow-AMSAA (NHPP)

2020-04-13T16:14:38Z

Sam Eisenberg: Updated failure terminated denominator per R-DE4648.

{{template:RGA BOOK|3.2|Crow-AMSAA}}
Dr. Larry H. Crow [[RGA_References|[17]]] noted that the [[Duane Model]] could be stochastically represented as a Weibull process, allowing for statistical procedures to be used in the application of this model in reliability growth. This statistical extension became what is known as the Crow-AMSAA (NHPP) model. This method was first developed at the U.S. Army Materiel Systems Analysis Activity (AMSAA). It is frequently used on systems when usage is measured on a continuous scale. It can also be applied for the analysis of one shot items when there is high reliability and a large number of trials.

Test programs are generally conducted on a phase by phase basis. The Crow-AMSAA model is designed for tracking the reliability within a test phase and not across test phases. A development testing program may consist of several separate test phases. If corrective actions are introduced during a particular test phase, then this type of testing and the associated data are appropriate for analysis by the Crow-AMSAA model. The model analyzes the reliability growth progress within each test phase and can aid in determining the following:

*Reliability of the configuration currently on test
*Reliability of the configuration on test at the end of the test phase
*Expected reliability if the test time for the phase is extended
*Growth rate
*Confidence intervals
*Applicable goodness-of-fit tests

==Background==
The reliability growth pattern for the Crow-AMSAA model is exactly the same pattern as for the [[Duane Model|Duane postulate]], that is, the cumulative number of failures is linear when plotted on ln-ln scale. Unlike the Duane postulate, the Crow-AMSAA model is statistically based. Under the Duane postulate, the failure rate is linear on ln-ln scale. However, for the Crow-AMSAA model statistical structure, the failure intensity of the underlying non-homogeneous Poisson process (NHPP) is linear when plotted on ln-ln scale.

Let <math>N(t)\,\!</math> be the cumulative number of failures observed in cumulative test time <math>t\,\!</math>, and let <math>\rho (t)\,\!</math> be the failure intensity for the Crow-AMSAA model. Under the NHPP model, <math>\rho (t)\Delta t\,\!</math> is approximately the probably of a failure occurring over the interval <math>[t,t+\Delta t]\,\!</math> for small <math>\Delta t\,\!</math>. In addition, the expected number of failures experienced over the test interval <math>[0,T]\,\!</math> under the Crow-AMSAA model is given by:

:<math>E[N(T)]=\int_{0}^{T}\rho (t)dt\,\!</math>

The Crow-AMSAA model assumes that <math>\rho (T)\,\!</math> may be approximated by the Weibull failure rate function:

:<math>\rho (T)=\frac{\beta }{{{\eta }^{\beta }}}{{T}^{\beta -1}}\,\!</math>

Therefore, if <math>\lambda =\tfrac{1}{{{\eta }^{\beta }}},\,\!</math> the intensity function, <math>\rho (T),\,\!</math> or the instantaneous failure intensity, <math>{{\lambda }_{i}}(T)\,\!</math>, is defined as:

:<math>{{\lambda }_{i}}(T)=\lambda \beta {{T}^{\beta -1}},\text{with }T>0,\text{ }\lambda >0\text{ and }\beta >0\,\!</math>

In the special case of exponential failure times, there is no growth and the failure intensity, <math>\rho (t)\,\!</math>, is equal to <math>\lambda \,\!</math>. In this case, the expected number of failures is given by:

:<math>\begin{align}
E[N(T)]= & \int_{0}^{T}\rho (t)dt \\
= & \lambda T
\end{align}\,\!</math>

In order for the plot to be linear when plotted on ln-ln scale under the general reliability growth case, the following must hold true where the expected number of failures is equal to:

:<math>\begin{align}
E[N(T)]= & \int_{0}^{T}\rho (t)dt \\
= & \lambda {{T}^{\beta }}
\end{align}\,\!</math>

To put a statistical structure on the reliability growth process, consider again the special case of no growth. In this case the number of failures, <math>N(T),\,\!</math> experienced during the testing over <math>[0,T]\,\!</math> is random. The expected number of failures, <math>N(T),\,\!</math> is said to follow the homogeneous (constant) Poisson process with mean <math>\lambda T\,\!</math> and is given by:

:<math>\underset{}{\overset{}{\mathop{\Pr }}}\,[N(T)=n]=\frac{{{(\lambda T)}^{n}}{{e}^{-\lambda T}}}{n!};\text{ }n=0,1,2,\ldots \,\!</math>

The Crow-AMSAA model generalizes this no growth case to allow for reliability growth due to corrective actions. This generalization keeps the Poisson distribution for the number of failures but allows for the expected number of failures, <math>E[N(T)],\,\!</math> to be linear when plotted on ln-ln scale. The Crow-AMSAA model lets <math>E[N(T)]=\lambda {{T}^{\beta }}\,\!</math>. The probability that the number of failures, <math>N(T),\,\!</math> will be equal to <math>n\,\!</math> under growth is then given by the Poisson distribution:

:<math>\underset{}{\overset{}{\mathop{\Pr }}}\,[N(T)=n]=\frac{{{(\lambda {{T}^{\beta }})}^{n}}{{e}^{-\lambda {{T}^{\beta }}}}}{n!};\text{ }n=0,1,2,\ldots \,\!</math>

This is the general growth situation, and the number of failures, <math>N(T)\,\!</math>, follows a non-homogeneous Poisson process. The exponential, "no growth" homogeneous Poisson process is a special case of the non-homogeneous Crow-AMSAA model. This is reflected in the Crow-AMSAA model parameter where <math>\beta =1\,\!</math>.
The cumulative failure rate, <math>{{\lambda }_{c}}\,\!</math>, is:

:<math>\begin{align}
{{\lambda }_{c}}=\lambda {{T}^{\beta -1}}
\end{align}\,\!</math>

The cumulative <math>MTB{{F}_{c}}\,\!</math> is:

:<math>MTB{{F}_{c}}=\frac{1}{\lambda }{{T}^{1-\beta }}\,\!</math>

As mentioned above, the local pattern for reliability growth within a test phase is the same as the growth pattern observed by [[Duane Model|Duane]]. The Duane <math>MTB{{F}_{c}}\,\!</math> is equal to:

:<math>MTB{{F}_{{{c}_{DUANE}}}}=b{{T}^{\alpha }}\,\!</math>

And the Duane cumulative failure rate, <math>{{\lambda }_{c}}\,\!</math>, is:

:<math>{{\lambda }_{{{c}_{DUANE}}}}=\frac{1}{b}{{T}^{-\alpha }}\,\!</math>

Thus a relationship between Crow-AMSAA parameters and Duane parameters can be developed, such that:

:<math>\begin{align}
{{b}_{DUANE}}= & \frac{1}{{{\lambda }_{AMSAA}}} \\
{{\alpha }_{DUANE}}= & 1-{{\beta }_{AMSAA}}
\end{align}\,\!</math>

Note that these relationships are not absolute. They change according to how the parameters (slopes, intercepts, etc.) are defined when the analysis of the data is performed. For the exponential case, <math>\beta =1\,\!</math>, then <math>{{\lambda }_{i}}(T)=\lambda \,\!</math>, a constant. For <math>\beta >1\,\!</math>, <math>{{\lambda }_{i}}(T)\,\!</math> is increasing. This indicates a deterioration in system reliability. For <math>\beta <1\,\!</math>, <math>{{\lambda }_{i}}(T)\,\!</math> is decreasing. This is indicative of reliability growth. Note that the model assumes a Poisson process with the Weibull intensity function, not the Weibull distribution. Therefore, statistical procedures for the Weibull distribution do not apply for this model. The parameter <math>\lambda \,\!</math> is called a scale parameter because it depends upon the unit of measurement chosen for <math>T\,\!</math>, while <math>\beta \,\!</math> is the shape parameter that characterizes the shape of the graph of the intensity function.

The total number of failures, <math>N(T)\,\!</math>, is a random variable with Poisson distribution. Therefore, the probability that exactly <math>n\,\!</math> failures occur by time <math>T\,\!</math> is:

:<math>P[N(T)=n]=\frac{{{[\theta (T)]}^{n}}{{e}^{-\theta (T)}}}{n!}\,\!</math>

The number of failures occurring in the interval from <math>{{T}_{1}}\,\!</math> to <math>{{T}_{2}}\,\!</math> is a random variable having a Poisson distribution with mean:

:<math>\theta ({{T}_{2}})-\theta ({{T}_{1}})=\lambda (T_{2}^{\beta }-T_{1}^{\beta })\,\!</math>

The number of failures in any interval is statistically independent of the number of failures in any interval that does not overlap the first interval. At time <math>{{T}_{0}}\,\!</math>, the failure intensity is <math>{{\lambda }_{i}}({{T}_{0}})=\lambda \beta T_{0}^{\beta -1}\,\!</math>. If improvements are not made to the system after time <math>{{T}_{0}}\,\!</math>, it is assumed that failures would continue to occur at the constant rate <math>{{\lambda }_{i}}({{T}_{0}})=\lambda \beta T_{0}^{\beta -1}\,\!</math>. Future failures would then follow an exponential distribution with mean <math>m({{T}_{0}})=\tfrac{1}{\lambda \beta T_{0}^{\beta -1}}\,\!</math>. The instantaneous MTBF of the system at time <math>T\,\!</math> is:

:<math>m(T)=\frac{1}{\lambda \beta {{T}^{\beta -1}}}\,\!</math>

<math>m(T)\,\!</math> is also called the demonstrated (or achieved) MTBF.

===Note About Applicability===
The [[Duane Model|Duane]] and Crow-AMSAA models are the most frequently used reliability growth models. Their relationship comes from the fact that both make use of the underlying observed linear relationship between the logarithm of cumulative MTBF and cumulative test time. However, the Duane model does not provide a capability to test whether the change in MTBF observed over time is significantly different from what might be seen due to random error between phases. The Crow-AMSAA model allows for such assessments. Also, the Crow-AMSAA allows for development of hypothesis testing procedures to determine growth presence in the data (where <math>\beta <1\,\!</math> indicates that there is growth in MTBF, <math>\beta =1\,\!</math> indicates a constant MTBF and <math>\beta >1\,\!</math> indicates a decreasing MTBF). Additionally, the Crow-AMSAA model views the process of reliability growth as probabilistic, while the Duane model views the process as deterministic.

==Failure Times Data==
A description of Failure Times Data is presented in the [[RGA Data Types#Failure_Times_Data|RGA Data Types]] page.
===Parameter Estimation for Failure Times Data=== 
The parameters for the Crow-AMSAA (NHPP) model are estimated using maximum likelihood estimation (MLE). The probability density function (''pdf'') of the <math>{{i}^{th}}\,\!</math> event given that the <math>{{(i-1)}^{th}}\,\!</math> event occurred at <math>{{T}_{i-1}}\,\!</math> is:

:<math>f({{T}_{i}}|{{T}_{i-1}})=\frac{\beta }{\eta }{{\left( \frac{{{T}_{i}}}{\eta } \right)}^{\beta -1}}\cdot {{e}^{-\tfrac{1}{{{\eta }^{\beta }}}\left( T_{i}^{\beta }-T_{i-1}^{\beta } \right)}}\,\!</math>

Let <math>\lambda =\tfrac{1}{{{\eta }^{\beta }}},\,\!</math>, the likelihood function is:

:<math>L={{\lambda }^{n}}{{\beta }^{n}}{{e}^{-\lambda {{T}^{*\beta }}}}\underset{i=1}{\overset{n}{\mathop \prod }}\,T_{i}^{\beta -1}\,\!</math>

where <math>{{T}^{*}}\,\!</math> is the termination time and is given by:

:<math>{{T}^{*}}=\left\{ \begin{matrix}
{{T}_{n}}\text{ if the test is failure terminated} \\
T>{{T}_{n}}\text{ if the test is time terminated} \\
\end{matrix} \right\}\,\!</math>

Taking the natural log on both sides:

:<math>\Lambda =n\ln \lambda +n\ln \beta -\lambda {{T}^{*\beta }}+(\beta -1)\underset{i=1}{\overset{n}{\mathop \sum }}\,\ln {{T}_{i}}\,\!</math>

And differentiating with respect to <math>\lambda \,\!</math> yields:

:<math>\frac{\partial \Lambda }{\partial \lambda }=\frac{n}{\lambda }-{{T}^{*\beta }}\,\!</math>

Set equal to zero and solve for <math>\lambda \,\!</math> :

:<math>\hat{\lambda }=\frac{n}{{{T}^{*\beta }}}\,\!</math>

Now differentiate with respect to <math>\beta \,\!</math> :

:<math>\frac{\partial \Lambda }{\partial \beta }=\frac{n}{\beta }-\lambda {{T}^{*\beta }}\ln {{T}^{*}}+\underset{i=1}{\overset{n}{\mathop \sum }}\,\ln {{T}_{i}}\,\!</math>

Set equal to zero and solve for <math>\beta \,\!</math> :

:<math>\hat{\beta }=\frac{n}{n\ln {{T}^{*}}-\underset{i=1}{\overset{n}{\mathop{\sum }}}\,\ln {{T}_{i}}}\,\!</math>

This equation is used for both failure terminated and time terminated test data.

====Biasing and Unbiasing of Beta==== 
The equation above returns the biased estimate, <math>\hat{\beta }\,\!</math>. The unbiased estimate, <math>\bar{\beta }\,\!</math>, can be calculated by using the following relationships. For time terminated data (the test ends after a specified test time):

:<math>\bar{\beta }=\frac{N-1}{N}\hat{\beta }\,\!</math>

For failure terminated data (the test ends after a specified number of failures):

:<math>\bar{\beta }=\frac{N-2}{N-1}\hat{\beta }\,\!</math>

By default <math>\hat{\beta }\,\!</math> is returned. <math>\bar{\beta }\,\!</math> can be returned by selecting the '''Calculate unbiased beta''' option on the Calculations tab of the Application Setup.

===Cramér-von Mises Test===
The Cramér-von Mises (CVM) goodness-of-fit test validates the hypothesis that the data follows a non-homogeneous Poisson process with a failure intensity equal to <math>u(t)=\lambda \beta {{t}^{\beta -1}}\,\!</math>. This test can be applied when the failure data is complete over the continuous interval <math>[0,{{T}_{q}}]\,\!</math> with no gaps in the data. The CVM data type applies to all data types when the failure times are known, except for Fleet data.

If the individual failure times are known, a Cramér-von Mises statistic is used to test the null hypothesis that a non-homogeneous Poisson process with the failure intensity function <math>\rho \left( t \right)=\lambda \,\beta \,{{t}^{\beta -1}}\left( \lambda >0,\beta >0,t>0 \right)\,\!</math> properly describes the reliability growth of a system. The Cramér-von Mises goodness-of-fit statistic is then given by the following expression:

:<math>C_{M}^{2}=\frac{1}{12M}+\underset{i=1}{\overset{M}{\mathop \sum }}\,{{\left[ {{\left( \frac{{{T}_{i}}}{T} \right)}^{{\bar{\beta }}}}-\frac{2i-1}{2M} \right]}^{2}}\,\!</math>

where:

:<math>M=\left\{ \begin{matrix}
N\text{ if the test is time terminated} \\
N-1\text{ if the test is failure terminated} \\
\end{matrix} \right\}\,\!</math>
:<math>{\bar{\beta }}\,\!</math> is the unbiased value of Beta.

The failure times, <math>{{T}_{i}}\,\!</math>, must be ordered so that <math>{{T}_{1}}<{{T}_{2}}<\ldots <{{T}_{M}}\,\!</math>.
If the statistic <math>C_{M}^{2}\,\!</math> is less than the critical value corresponding to <math>M\,\!</math> for a chosen significance level, then you can fail to reject the null hypothesis that the Crow-AMSAA model adequately fits the data.

====Critical Values====
The following table displays the critical values for the Cramér-von Mises goodness-of-fit test given the sample size, <math>M\,\!</math>, and the significance level, <math>\alpha \,\!</math>.

{|border="1" align="center" style="border-collapse: collapse;" cellpadding="5" cellspacing="5"
|-
|colspan="6" style="text-align:center"|'''Critical values for Cramér-von Mises test'''
|-
| ||colspan="5" style="text-align:center;"|<math>\alpha \,\!</math>
|-
|<math>M\,\!</math>|| 0.20|| 0.15|| 0.10|| 0.05|| 0.01
|-
|2|| 0.138|| 0.149|| 0.162|| 0.175|| 0.186
|-
|3|| 0.121|| 0.135|| 0.154|| 0.184||0.23
|-
|4|| 0.121|| 0.134|| 0.155|| 0.191||0.28
|-
|5|| 0.121|| 0.137|| 0.160|| 0.199||0.30
|-
|6|| 0.123|| 0.139|| 0.162|| 0.204||0.31
|-
|7|| 0.124|| 0.140|| 0.165|| 0.208||0.32
|-
|8|| 0.124|| 0.141|| 0.165|| 0.210||0.32
|-
|9|| 0.125|| 0.142|| 0.167|| 0.212||0.32
|-
|10|| 0.125|| 0.142|| 0.167|| 0.212||0.32
|-
|11|| 0.126|| 0.143|| 0.169|| 0.214||0.32
|-
|12|| 0.126|| 0.144|| 0.169|| 0.214||0.32
|-
|13|| 0.126|| 0.144|| 0.169|| 0.214||0.33
|-
|14|| 0.126|| 0.144|| 0.169|| 0.214||0.33
|-
|15|| 0.126|| 0.144|| 0.169|| 0.215||0.33
|-
|16|| 0.127|| 0.145|| 0.171|| 0.216|| 0.33
|-
|17|| 0.127|| 0.145|| 0.171|| 0.217|| 0.33
|-
|18|| 0.127|| 0.146|| 0.171|| 0.217|| 0.33
|-
|19|| 0.127|| 0.146|| 0.171|| 0.217|| 0.33
|-
|20|| 0.128|| 0.146|| 0.172|| 0.217|| 0.33
|-
|30|| 0.128|| 0.146|| 0.172|| 0.218|| 0.33
|-
|60|| 0.128|| 0.147|| 0.173|| 0.220|| 0.33
|-
|100|| 0.129|| 0.147|| 0.173|| 0.220|| 0.34
|}

The significance level represents the probability of rejecting the hypothesis even if it's true. So, there is a risk associated with applying the goodness-of-fit test (i.e., there is a chance that the CVM will indicate that the model does not fit, when in fact it does). As the significance level is increased, the CVM test becomes more stringent. Keep in mind that the CVM test passes when the test statistic is less than the critical value. Therefore, the larger the critical value, the more room there is to work with (e.g., a CVM test with a significance level equal to 0.1 is more strict than a test with 0.01).

===Confidence Bounds===
The RGA software provides two methods to estimate the confidence bounds for the Crow Extended model when applied to developmental testing data. The Fisher Matrix approach is based on the Fisher Information Matrix and is commonly employed in the reliability field. The Crow bounds were developed by Dr. Larry Crow. See the [[Crow-AMSAA Confidence Bounds]] chapter for details on how the confidence bounds are calculated.

===Failure Times Data Examples===
====Example - Parameter Estimation====

{{:Crow-AMSAA Parameter Estimation Example}}

{{:Crow-AMSAA_Confidence_Bounds_Example}}

==Multiple Systems==
When more than one system is placed on test during developmental testing, there are multiple data types which are available depending on the testing strategy and the format of the data. The data types that allow for the analysis of multiple systems using the Crow-AMSAA (NHPP) model are given below:

*[[Crow-AMSAA_(NHPP)#Multiple Systems (Known Operating Times)|Multiple Systems (Known Operating Times)]]
*[[Crow-AMSAA_(NHPP)#Multiple Systems (Concurrent Operating Times)|Multiple Systems (Concurrent Operating Times)]]
*[[Crow-AMSAA_(NHPP)#Multiple Systems with Dates|Multiple Systems with Dates]]

===Goodness-of-fit Tests===
For all multiple systems data types, the [[Crow-AMSAA (NHPP)#Cram.C3.A9r-von_Mises_Test|Cramér-von Mises (CVM) Test]] is available. For Multiple Systems (Concurrent Operating Times) and Multiple Systems with Dates, two additional tests are also available: [[Hypothesis Tests#Laplace_Trend_Test|Laplace Trend Test]] and [[Hypothesis Tests#Common_Beta_Hypothesis_Test|Common Beta Hypothesis]].

===Multiple Systems (Known Operating Times)===

A description of Multiple Systems (Known Operating Times) is presented on the [[RGA Data Types#Multiple_Systems_.28Known_Operating_Times.29|RGA Data Types]] page.

Consider the data in the table below for two prototypes that were placed in a reliability growth test.

<center>'''Developmental Test Data for Two Identical Systems''' </center>
{|border="1" align="center" style="border-collapse: collapse;" cellpadding="5" cellspacing="5"
!Failure Number
!Failed Unit
!Test Time Unit 1 (hr)
!Test Time Unit 2 (hr)
!Total Test Time (hr)
!<math>ln{(T)}\,\!</math>
|-
|1|| 1|| 1.0|| 1.7|| 2.7|| 0.99325
|-
|2|| 1|| 7.3|| 3.0|| 10.3|| 2.33214
|-
|3|| 2|| 8.7|| 3.8|| 12.5|| 2.52573
|-
|4|| 2|| 23.3|| 7.3|| 30.6|| 3.42100
|-
|5|| 2|| 46.4|| 10.6|| 57.0|| 4.04305
|-
|6|| 1|| 50.1|| 11.2|| 61.3|| 4.11578
|-
|7|| 1|| 57.8|| 22.2|| 80.0|| 4.38203
|-
|8|| 2|| 82.1|| 27.4|| 109.5|| 4.69592
|-
|9|| 2|| 86.6|| 38.4|| 125.0||4.82831
|-
|10|| 1|| 87.0|| 41.6|| 128.6|| 4.85671
|-
|11|| 2|| 98.7|| 45.1|| 143.8|| 4.96842
|-
|12|| 1|| 102.2|| 65.7|| 167.9|| 5.12337
|-
|13|| 1|| 139.2 ||90.0||229.2|| 5.43459
|-
|14|| 1|| 166.6|| 130.1|| 296.7|| 5.69272
|-
|15|| 2|| 180.8|| 139.8 ||320.6||5.77019
|-
|16|| 1|| 181.3|| 146.9|| 328.2|| 5.79362
|-
|17|| 2|| 207.9|| 158.3 ||366.2||5.90318
|-
|18|| 2|| 209.8|| 186.9|| 396.7|| 5.98318
|-
|19|| 2|| 226.9|| 194.2|| 421.1|| 6.04287
|-
|20|| 1|| 232.2|| 206.0|| 438.2|| 6.08268
|-
|21|| 2|| 267.5|| 233.7|| 501.2|| 6.21701
|-
|22|| 2|| 330.1|| 289.9|| 620.0|| 6.42972
|}

The Failed Unit column indicates the system that failed and is meant to be informative, but it does not affect the calculations. To combine the data from both systems, the system ages are added together at the times when a failure occurred. This is seen in the Total Test Time column above. Once the single timeline is generated, then the calculations for the parameters Beta and Lambda are the same as the process presented for [[Crow-AMSAA (NHPP)#Parameter_Estimation_for_Failure_Times_Data|Failure Times Data]]. The results of this analysis would match the results of [[Crow-AMSAA (NHPP)#Failure_Times_-_Example_1|Failure Times - Example 1]].

===Multiple Systems (Concurrent Operating Times)===
A description of Multiple Systems (Concurrent Operating Times) is presented on the [[RGA Data Types#Multiple_Systems_.28Concurrent_Operating_Times.29|RGA Data Types]] page.

====Parameter Estimation for Multiple Systems (Concurrent Operating Times)====
To estimate the parameters, the equivalent system must first be determined. The equivalent single system (ESS) is calculated by summing the usage across all systems when a failure occurs. Keep in mind that Multiple Systems (Concurrent Operating Times) assumes that the systems are running simultaneously and accumulate the same usage. If the systems have different end times then the equivalent system must only account for the systems that are operating when a failure occurred. Systems with a start time greater than zero are shifted back to t = 0. This is the same as having a start time equal to zero and the converted end time is equal to the end time minus the start time. In addition, all failures times are adjusted by subtracting the start time from each value to ensure that all values occur within t = 0 and the adjusted end time. A start time greater than zero indicates that it is not known as to what events occurred at a time less than the start time. This may have been caused by the events during this period not being tracked and/or recorded properly.

As an example, consider two systems have entered a reliability growth test. Both systems have a start time equal to zero and both begin the test with the same configuration. System 1 operated for 100 hours and System 2 operated for 125 hours. The failure times for each system are given below:

*System 1: 25, 47, 80
*System 2: 15, 62, 89, 110

To build the ESS, the total accumulated hours across both systems is taken into account when a failure occurs. Therefore, given the data for Systems 1 and 2, the ESS is comprised of the following events: 30, 50, 94, 124, 160, 178, 210.

The ESS combines the data from both systems into a single timeline. The termination time for the ESS is (100 + 125) = 225 hours. The parameter estimates for <math>\hat{\beta }\,\!</math> and <math>\hat{\lambda}\,\!</math> are then calculated using the ESS. This process is the same as the method for [[Crow-AMSAA (NHPP)#Parameter_Estimation_for_Failure_Times_Data|Failure Times data]].

====Example - Concurrent Operating Times====
{{:Concurrent Operating Times - Crow-AMSAA (NHPP) Example}}

===Multiple Systems with Dates===
An overview of the Multiple Systems with Dates data type is presented on the [[RGA Data Types#Multiple_Systems_with_Dates|RGA Data Types]] page. While Multiple Systems with Dates requires a date for each event, including the start and end times for each system, once the equivalent single system is determined, the parameter estimation is the same as it is for Multiple Systems (Concurrent Operating Times). See [[Crow-AMSAA_(NHPP)#Parameter_Estimation_for_Multiple_Systems_.28Concurrent_Operating_Times.29|Parameter Estimation for Multiple Systems (Concurrent Operating Times)]] for details.

==Grouped Data== 
A description of Grouped Data is presented in the [[RGA Data Types#Grouped_Failure_Times|RGA Data Types]] page.
===Parameter Estimation for Grouped Data===
For analyzing grouped data, we follow the same logic described previously for the [[Duane Model|Duane]] model. If the <math>E[N(T)]\,\!</math> equation from the [[Crow-AMSAA_(NHPP)#Background|Background]] section above is linearized:

:<math>\begin{align}
\ln [E(N(T))]=\ln \lambda +\beta \ln T
\end{align}\,\!</math>

According to Crow [[RGA_References|[9]]], the likelihood function for the grouped data case, (where <math>{{n}_{1}},\,\!</math> <math>{{n}_{2}},\,\!</math> <math>{{n}_{3}},\ldots ,\,\!</math> <math>{{n}_{k}}\,\!</math> failures are observed and <math>k\,\!</math> is the number of groups), is:

:<math>\underset{i=1}{\overset{k}{\mathop \prod }}\,\underset{}{\overset{}{\mathop{\Pr }}}\,({{N}_{i}}={{n}_{i}})=\underset{i=1}{\overset{k}{\mathop \prod }}\,\frac{{{(\lambda T_{i}^{\beta }-\lambda T_{i-1}^{\beta })}^{{{n}_{i}}}}\cdot {{e}^{-(\lambda T_{i}^{\beta }-\lambda T_{i-1}^{\beta })}}}{{{n}_{i}}!}\,\!</math>

And the MLE of <math>\lambda \,\!</math> based on this relationship is:

:<math>\hat{\lambda }=\frac{n}{T_{k}^{\hat{\beta }}}\,\!</math>

where <math>n \,\!</math> is the total number of failures from all the groups.

The estimate of <math>\beta \,\!</math> is the value <math>\hat{\beta }\,\!</math> that satisfies:

:<math>\underset{i=1}{\overset{k}{\mathop \sum }}\,{{n}_{i}}\left[ \frac{T_{i}^{\hat{\beta }}\ln {{T}_{i}}-T_{i-1}^{\hat{\beta }}\ln {{T}_{i-1}}}{T_{i}^{\hat{\beta }}-T_{i-1}^{\hat{\beta }}}-\ln {{T}_{k}} \right]=0\,\!</math>

See [[Crow-AMSAA Confidence Bounds#Grouped_Data|Crow-AMSAA Confidence Bounds]] for details on how confidence bounds for grouped data are calculated.

===Chi-Squared Test===
A chi-squared goodness-of-fit test is used to test the null hypothesis that the Crow-AMSAA reliability model adequately represents a set of grouped data. This test is applied only when the data is grouped. The expected number of failures in the interval from <math>{{T}_{i-1}}\,\!</math> to <math>{{T}_{i}}\,\!</math> is approximated by:

:<math>{{\hat{\theta }}_{i}}=\hat{\lambda }\left( T_{i}^{{\hat{\beta }}}-T_{i-1}^{{\hat{\beta }}} \right)\,\!</math>

For each interval, <math>{{\hat{\theta }}_{i}}\,\!</math> shall not be less than 5 and, if necessary, adjacent intervals may have to be combined so that the expected number of failures in any combined interval is at least 5. Let the number of intervals after this recombination be <math>d\,\!</math>, and let the observed number of failures in the <math>{{i}^{th}}\,\!</math> new interval be <math>{{N}_{i}}\,\!</math>. Finally, let the expected number of failures in the <math>{{i}^{th}}\,\!</math> new interval be <math>{{\hat{\theta }}_{i}}\,\!</math>. Then the following statistic is approximately distributed as a chi-squared random variable with degrees of freedom <math>d-2\,\!</math>.

:<math>{{\chi }^{2}}=\underset{i=1}{\overset{d}{\mathop \sum }}\,\frac{{{({{N}_{i}}-{{\hat{\theta }}_{i}})}^{2}}}{{{\hat{\theta }}_{i}}}\,\!</math>

The null hypothesis is rejected if the <math>{{\chi }^{2}}\,\!</math> statistic exceeds the critical value for a chosen significance level. In this case, the hypothesis that the Crow-AMSAA model adequately fits the grouped data shall be rejected. Critical values for this statistic can be found in chi-squared distribution tables.

===Grouped Data Examples===
====Example - Simple Grouped====
{{:Crow-AMSAA_Model_-_Grouped_Data_Example}}

====Example - Helicopter System====
{{:Crow-AMSAA_Model_-_Helicopter_System_Example}}

<div class="noprint">
{{Examples Box|RGA Examples|<p>More grouped data examples are available! See also:</p>
{{Examples Link External|http://www.reliasoft.com/rga/examples/rgex1/index.htm|Simple MTBF Determination}}<nowiki/>
}}
</div>




==Missing Data==
{{:Gap Analysis}}

==Discrete Data==

The Crow-AMSAA model can be adapted for the analysis of ''success/failure'' data (also called ''discrete'' or ''attribute'' data). The following discrete data types are available:

*Sequential
*Grouped per Configuration
*Mixed

Sequential data and Grouped per Configuration are very similar as the parameter estimation methodology is the same for both data types. Mixed data is a combination of Sequential Data and Grouped per Configuration and is presented in [[Crow-AMSAA (NHPP)#Mixed_Data|Mixed Data]].

===Grouped per Configuration===
Suppose system development is represented by <math>i\,\!</math> configurations. This corresponds to <math>i-1\,\!</math> configuration changes, unless fixes are applied at the end of the test phase, in which case there would be <math>i\,\!</math> configuration changes. Let <math>{{N}_{i}}\,\!</math> be the number of trials during configuration <math>i\,\!</math> and let <math>{{M}_{i}}\,\!</math> be the number of failures during configuration <math>i\,\!</math>. Then the cumulative number of trials through configuration <math>i\,\!</math>, namely <math>{{T}_{i}}\,\!</math>, is the sum of the <math>{{N}_{i}}\,\!</math> for all <math>i\,\!</math>, or:

:<math>{{T}_{i}}=\underset{}{\overset{}{\mathop \sum }}\,{{N}_{i}}\,\!</math>

And the cumulative number of failures through configuration <math>i\,\!</math>, namely <math>{{K}_{i}}\,\!</math>, is the sum of the <math>{{M}_{i}}\,\!</math> for all <math>i\,\!</math>, or:

:<math>{{K}_{i}}=\underset{}{\overset{}{\mathop \sum }}\,{{M}_{i}}\,\!</math>

The expected value of <math>{{K}_{i}}\,\!</math> can be expressed as <math>E[{{K}_{i}}]\,\!</math> and defined as the expected number of failures by the end of configuration <math>i\,\!</math>. Applying the learning curve property to <math>E[{{K}_{i}}]\,\!</math> implies:

:<math>E\left[ {{K}_{i}} \right]=\lambda T_{i}^{\beta }\,\!</math>

Denote <math>{{f}_{1}}\,\!</math> as the probability of failure for configuration 1 and use it to develop a generalized equation for <math>{{f}_{i}}\,\!</math> in terms of the <math>{{T}_{i}}\,\!</math> and <math>{{N}_{i}}\,\!</math>. From the equation above, the expected number of failures by the end of configuration 1 is:

:<math>E\left[ {{K}_{1}} \right]=\lambda T_{1}^{\beta }={{f}_{1}}{{N}_{1}}\,\!</math>

:<math>\therefore {{f}_{1}}=\frac{\lambda T_{1}^{\beta }}{{{N}_{1}}}\,\!</math>

Applying the <math>E\left[ {{K}_{i}}\right]\,\!</math> equation again and noting that the expected number of failures by the end of configuration 2 is the sum of the expected number of failures in configuration 1 and the expected number of failures in configuration 2:

:<math>\begin{align}
E\left[ {{K}_{2}} \right] = & \lambda T_{2}^{\beta } \\
= & {{f}_{1}}{{N}_{1}}+{{f}_{2}}{{N}_{2}} \\
= & \lambda T_{1}^{\beta }+{{f}_{2}}{{N}_{2}}
\end{align}\,\!</math>

:<math>\therefore {{f}_{2}}=\frac{\lambda T_{2}^{\beta }-\lambda T_{1}^{\beta }}{{{N}_{2}}}\,\!</math>

By this method of inductive reasoning, a generalized equation for the failure probability on a configuration basis, <math>{{f}_{i}}\,\!</math>, is obtained, such that:

:<math>{{f}_{i}}=\frac{\lambda T_{i}^{\beta }-\lambda T_{i-1}^{\beta }}{{{N}_{i}}}\,\!</math>

In this equation, <math>i\,\!</math> represents the trial number. Thus, an equation for the reliability (probability of success) for the <math>{{i}^{th}}\,\!</math> configuration is obtained:

:<math>\begin{align}
{{R}_{i}}=1-{{f}_{i}}
\end{align}\,\!</math>

===Sequential Data===
From the [[Crow-AMSAA (NHPP)#Grouped_per_Configuration|Grouped per Configuration]] section, the following equation is given:

:<math>{{f}_{i}}=\frac{\lambda T_{i}^{\beta }-\lambda T_{i-1}^{\beta }}{{{N}_{i}}}\,\!</math>

For the special case where <math>{{N}_{i}}=1\,\!</math> for all <math>i\,\!</math>, the equation above becomes a smooth curve, <math>{{g}_{i}}\,\!</math>, that represents the probability of failure for trial by trial data, or:

:<math>{{g}_{i}}=\lambda \cdot {{i}^{\beta }}-\lambda \cdot {{\left( i-1 \right)}^{\beta }}\,\!</math>

When <math>{{N}_{i}}=1\,\!</math>, this is the same as Sequential Data where systems are tested on a trial-by-trial basis. The equation for the reliability for the <math>{{i}^{th}}\,\!</math> trial is:

:<math>\begin{align}
{{R}_{i}}=1-{{g}_{i}}
\end{align}\,\!</math>

===Parameter Estimation for Discrete Data===
This section describes procedures for estimating the parameters of the Crow-AMSAA model for success/failure data which includes Sequential data and Grouped per Configuration. An example is presented illustrating these concepts. The estimation procedures provide maximum likelihood estimates (MLEs) for the model's two parameters, <math>\lambda \,\!</math> and <math>\beta \,\!</math>. The MLEs for <math>\lambda \,\!</math> and <math>\beta \,\!</math> allow for point estimates for the probability of failure, given by:

:<math>{{\hat{f}}_{i}}=\frac{\hat{\lambda }T_{i}^{{\hat{\beta }}}-\hat{\lambda }T_{i-1}^{{\hat{\beta }}}}{{{N}_{i}}}=\frac{\hat{\lambda }\left( T_{i}^{{\hat{\beta }}}-T_{i-1}^{{\hat{\beta }}} \right)}{{{N}_{i}}}\,\!</math>

And the probability of success (reliability) for each configuration <math>i\,\!</math> is equal to:

:<math>{{\hat{R}}_{i}}=1-{{\hat{f}}_{i}}\,\!</math>

The likelihood function is:

:<math>\underset{i=1}{\overset{k}{\mathop \prod }}\,\left( \begin{matrix}
{{N}_{i}} \\
{{M}_{i}} \\
\end{matrix} \right){{\left( \frac{\lambda T_{i}^{\beta }-\lambda T_{i-1}^{\beta }}{{{N}_{i}}} \right)}^{{{M}_{i}}}}{{\left( \frac{{{N}_{i}}-\lambda T_{i}^{\beta }+\lambda T_{i-1}^{\beta }}{{{N}_{i}}} \right)}^{{{N}_{i}}-{{M}_{i}}}}\,\!</math>

Taking the natural log on both sides yields:

:<math>\begin{align}
& \Lambda = & \underset{i=1}{\overset{K}{\mathop \sum }}\,\left[ \ln \left( \begin{matrix}
{{N}_{i}} \\
{{M}_{i}} \\
\end{matrix} \right)+{{M}_{i}}\left[ \ln (\lambda T_{i}^{\beta }-\lambda T_{i-1}^{\beta })-\ln {{N}_{i}} \right] \right] \\
& & +\underset{i=1}{\overset{K}{\mathop \sum }}\,\left[ ({{N}_{i}}-{{M}_{i}})\left[ \ln ({{N}_{i}}-\lambda T_{i}^{\beta }+\lambda T_{i-1}^{\beta })-\ln {{N}_{i}} \right] \right]
\end{align}\,\!</math>

Taking the derivative with respect to <math>\lambda \,\!</math> and <math>\beta \,\!</math> respectively, exact MLEs for <math>\lambda \,\!</math> and <math>\beta \,\!</math> are values satisfying the following two equations:

:<math>\begin{align}
& \underset{i=1}{\overset{K}{\mathop \sum }}\,{{H}_{i}}\times {{S}_{i}}= & 0 \\
& \underset{i=1}{\overset{K}{\mathop \sum }}\,{{U}_{i}}\times {{S}_{i}}= & 0
\end{align}\,\!</math>

where:

:<math>\begin{align}
{{H}_{i}}= & \left[ T_{i}^{\beta }\ln {{T}_{i}}-T_{i-1}^{\beta }\ln {{T}_{i-1}} \right] \\
{{S}_{i}}= & \frac{{{M}_{i}}}{\left[ \lambda T_{i}^{\beta }-\lambda T_{i-1}^{\beta } \right]}-\frac{{{N}_{i}}-{{M}_{i}}}{\left[ {{N}_{i}}-\lambda T_{i}^{\beta }+\lambda T_{i-1}^{\beta } \right]} \\
{{U}_{i}}= & T_{i}^{\beta }-T_{i-1}^{\beta }\,
\end{align}\,\!</math>

===Example - Grouped per Configuration===
{{:Crow-AMSAA Discrete Model Example}}

===Mixed Data===
The Mixed data type provides additional flexibility in terms of how it can handle different testing strategies. Systems can be tested using different configurations in groups or individual trial by trial, or a mixed combination of individual trials and configurations of more than one trial. The Mixed data type allows you to enter the data so that it represents how the systems were tested within the total number of trials. For example, if you launched five (5) missiles for a given configuration and none of them failed during testing, then there would be a row within the data sheet indicating that this configuration operated successfully for these five trials. If the very next trial, the sixth, failed then this would be a separate row within the data. The flexibility with the data entry allows for a greater understanding in terms of how the systems were tested by simply examining the data. The methodology for estimating the parameters <math>\hat{\beta }\,\!</math> and <math>\hat{\lambda}\,\!</math> are the same as those presented in the [[Crow-AMSAA (NHPP)#Grouped_Data|Grouped Data]] section. With Mixed data, the average reliability and average unreliability within a given interval can also be calculated.

The average unreliability is calculated as:

:<math>\text{Average Unreliability }({{t}_{1,}}{{t}_{2}})=\frac{\lambda t_{2}^{\beta }-\lambda t_{1}^{\beta }}{{{t}_{2}}-{{t}_{1}}}\,\!</math>

and the average reliability is calculated as:

:<math>\text{Average Reliability }({{t}_{1,}}{{t}_{2}})=1-\frac{\lambda t_{2}^{\beta }-\lambda t_{1}^{\beta }}{{{t}_{2}}-{{t}_{1}}}\,\!</math>

====Mixed Data Confidence Bounds====
'''Bounds on Average Failure Probability'''<br>
The process to calculate the average unreliability confidence bounds for Mixed data is as follows:

#Calculate the average failure probability <math>({{t}_{1}},{{t}_{2}})\,\!</math>.
#There will exist a <math>{{t}^{*}}\,\!</math> between <math>{{t}_{1}}\,\!</math> and <math>{{t}_{2}}\,\!</math> such that the instantaneous unreliability at <math>{{t}^{*}}\,\!</math> equals the average unreliability <math>({{t}_{1}},{{t}_{2}})\,\!</math>. The confidence intervals for the instantaneous unreliability at <math>{{t}^{*}}\,\!</math> are the confidence intervals for the average unreliability <math>({{t}_{1}},{{t}_{2}})\,\!</math>.

'''Bounds on Average Reliability'''<br>
The process to calculate the average reliability confidence bounds for Mixed data is as follows:

#Calculate confidence bounds for average unreliability <math>({{t}_{1}},{{t}_{2}})\,\!</math> as described above.
#The confidence bounds for reliability are 1 minus these confidence bounds for average unreliability.

====Example - Mixed Data====
{{:Crow-AMSAA Discrete Model Grouped Data Example}}

==Change of Slope==
{{:Change of Slope Analysis}}

==More Examples==
===Determining Whether a Design Meets the MTBF Goal===
{{:Failure_Times_Crow-AMSAA_Example}}

===Analyzing Mixed Data for a One-Shot System===
{{:Mixed_Data_-_Crow-AMSAA_Example}}

Fault Tree Diagrams and System Analysis

2019-11-27T21:25:00Z

Sam Eisenberg: /* Trigger Event */

{{Template:bsbook|9}}
BlockSim allows system modeling using both reliability block diagrams (RBDs) and fault trees. This chapter introduces basic fault tree analysis and points out the similarities (and differences) between RBDs and fault tree diagrams. Principles, methods and concepts discussed in previous chapters are used.

Fault trees and reliability block diagrams are both symbolic analytical logic techniques that can be applied to analyze system reliability and related characteristics. Although the symbols and structures of the two diagram types differ, most of the logical constructs in a fault tree diagram (FTD) can also be modeled with a reliability block diagram (RBD). This chapter presents a brief introduction to fault tree analysis concepts and illustrates the similarities between fault tree diagrams and reliability block diagrams.

=Fault Tree Analysis: Brief Introduction=
Bell Telephone Laboratories developed the concept of fault tree analysis in 1962 for the U.S. Air Force for use with the Minuteman system. It was later adopted and extensively applied by the Boeing Company. A fault tree diagram follows a top-down structure and represents a graphical model of the pathways within a system that can lead to a foreseeable, undesirable loss event (or a failure). The pathways interconnect contributory events and conditions using standard logic symbols (AND, OR, etc.).

Fault tree diagrams consist of gates and events connected with lines. The AND and OR gates are the two most commonly used gates in a fault tree. To illustrate the use of these gates, consider two events (called "input events") that can lead to another event (called the "output event"). If the occurrence of either input event causes the output event to occur, then these input events are connected using an OR gate. Alternatively, if both input events must occur in order for the output event to occur, then they are connected by an AND gate. The following figure shows a simple fault tree diagram in which either ''A'' or ''B'' must occur in order for the output event to occur. In this diagram, the two events are connected to an OR gate. If the output event is system failure and the two input events are component failures, then this fault tree indicates that the failure of ''A'' or ''B'' causes the system to fail.

[[Image:1.png|center|200px|Fault tree where the occurrence of either ''A'' or ''B'' can cause system failure.|link=]]

The RBD equivalent for this configuration is a simple series system with two blocks, ''A'' and ''B'', as shown next.

[[Image:10.2.png|center|200px|The RBD representation of the fault tree.|link=]]

=Basic Gates=
Gates are the logic symbols that interconnect contributory events and conditions in a fault tree diagram. The AND and OR gates described above, as well as a Voting OR gate in which the output event occurs if a certain number of the input events occur (i.e., ''k''-out-of-''n'' redundancy), are the most basic types of gates in classical fault tree analysis. These gates are explicitly provided for in BlockSim and are described in this section along with their BlockSim implementations. Additional gates are introduced in the following sections.

A fault tree diagram is always drawn in a top-down manner with lowest item being a basic event block. Classical fault tree gates have no properties (i.e., they cannot fail).

{{:AND Gate Example}}

{{:OR Gate Example}}

{{:Voting OR Gate Example}}

===Combining Basic Gates===
As in reliability block diagrams where different configuration types can be combined in the same diagram, fault tree analysis gates can also be combined to create more complex representations. As an example, consider the fault tree diagram shown in the figures below.

[[Image:10.5.png|center|600px|A sample FTD using different gates.|link=]]

[[Image:10.6.png|center|250px|RBD representation of the FTD shown in figure above.|link=]]

=New BlockSim Gates=

In addition to the gates defined above, other gates exist in classical FTA. These additional gates (e.g., Sequence Enforcing, Priority AND, etc.) are usually used to describe more complex redundancy configurations and are described in later sections. First, we will introduce two new advanced gates that can be used to append to and/or replace classical fault tree gates.
These two new gates are the Load Sharing and Standby gates. Classical fault trees (or any other fault tree standard to our knowledge) do not allow for load sharing redundancy (or event dependency). To overcome this limitation, and to provide fault trees with the same flexibility as BlockSim's RBDs, we will define a Load Sharing gate in this section. Additionally, traditional fault trees do not provide the full capability to model standby redundancy configurations (including the quiescent failure distribution), although basic standby can be represented in traditional fault tree diagrams using a Priority AND gate or a Sequence Enforcing gate, discussed in later sections.

===Load Sharing Gate===

[[Image:I10.10.png|center|100px|link=|]]

A Load Sharing gate behaves just like BlockSim's Load Sharing containers for RBDs. Load Sharing containers were discussed in [[Time-Dependent_System_Reliability_(Analytical)|Time-Dependent System Reliability (Analytical)]] and [[RBDs_and_Analytical_System_Reliability|RBDs and Analytical System Reliability]]. Events leading into a Load Sharing gate have distributions and life-stress relationships, just like contained blocks. Furthermore, the gate defines the load and the number required to cause the output event (i.e., the Load Sharing gate is defined with a ''k''-out-of-''n'' vote ). In BlockSim, no additional gates are allowed below a Load Sharing gate.

====Example====
{{:Example_Using_Load_Sharing_Gates_in_Fault_Trees}}

{{:Standby Gate Example}}

=Additional Classical Gates and Their Equivalents in BlockSim=
===Sequence Enforcing Gate===
Various graphical symbols have been used to represent a Sequence Enforcing gate. It is a variation of an AND gate in which each item must happen in sequence. In other words, events are constrained to occur in a specific sequence and the output event occurs if all input events occur in that specified sequence. This is identical to a cold standby redundant configuration (i.e., <math>k\,\!</math> units in standby with no quiescent failure distribution and no switch failure probability). BlockSim does not explicitly provide a Sequence Enforcing gate; however, it can be easily modeled using the more advanced Standby gate, described previously.

===Inhibit Gate===
In an Inhibit gate, the output event occurs if all input events occur and an additional conditional event occurs. It is an AND gate with an additional event. In reality, an Inhibit gate provides no additional modeling capabilities but is used to illustrate the fact that an additional event must also occur. As an example, consider the case where events ''A'' and ''B'' must occur as well as a third event ''C'' (the so-called conditional event) in order for the system to fail. One can represent this in a fault tree by using an AND gate with three events, ''A'', ''B'' and ''C'', as shown next.

[[Image:inhibit_and.png|center|200px|Using an AND gate to represent an inhibit relationship.|link=]]

Classical fault tree diagrams have the conditional event drawn to the side and the gate drawn as a hexagon, as shown next.

[[Image:11.png|center|200px|Traditional use of an Inhibit gate.|link=]]

It should be noted that both representations are equivalent from an analysis standpoint.

BlockSim explicitly provides an Inhibit gate. This gate functions just like an AND gate with the exception that failure/repair characteristics can be assigned to the gate itself. This allows the construction shown above (if the gate itself is set to not fail). Additionally, one could encapsulate event ''C'' inside the gate (since the gate can have properties), as shown next. Note that all three figures can be represented using a single RBD with events ''A'', ''B'' and ''C'' in parallel.

[[Image:10.12.png|center|200px|Including the conditional event inside the Inhibit gate.|link=]]

===Priority AND Gate===

[[Image:10_13.png|center|100px|link=|]]

With a Priority AND gate, the output event occurs if all input events occur in a specific sequence. This is an AND gate that requires that all events occur in a specific sequence. At first, this may seem identical to the Sequence Enforcing gate discussed earlier. However, it differs from this gate in the fact that events can occur out of sequence (i.e., are not constrained to occur in a specific sequence) but the output event only occurs if the sequence is followed. To better illustrate this, consider the case of two motors in standby configuration with motor <math>A\,\!</math> being the primary motor and motor ''B'' in standby. If motor ''A'' fails, then the switch (which can also fail) activates motor ''B''. Then the system will fail if motor ''A'' fails and the switch fails to switch, or if the switch succeeds but motor ''B'' fails subsequent to the switching action. In this scenario, the events must occur in the order noted; however, it is possible for the switch or motor ''B'' to fail (in a quiescent mode) without causing a system failure, if ''A'' never fails. BlockSim does not explicitly provide a Priority AND gate. However, like the Sequence Enforcing gate, it can be easily modeled using the more advanced Standby gate.

===Transfer Gate===
[[Image:10_14.png|center|100px|link=|]]

Transfer in/out gates are used to indicate a transfer/continuation of one fault tree to another. In classical fault trees, the Transfer gate is generally used to signify the continuation of a tree on a separate sheet. This is the same as a subdiagram block in an RBD. BlockSim does not explicitly provide a Transfer gate. However, it does allow for subdiagrams (or sub-trees), which provide for greater flexibility. Additionally, a subdiagram in a BlockSim fault tree can be an RBD and vice versa. BlockSim uses the more intuitive folder symbol to represent subdiagrams.

[[Image:10_15.png|center|100px|link=|]]

As an example, consider the fault tree of the robot manipulator shown in the first figure ("A") below. The second figure ("B") illustrates the same fault tree with the use of subdiagrams (Transfer gates). The referenced subdiagrams are shown in subsequent figures. Note that this is using multiple levels of indenture (i.e., the subdiagram has subdiagrams and so forth).

[[Image:BS10.13.png|center|600px|thumb|A: A sample fault tree for a robot manipulator, showing all items in a single tree.|link=]]

[[Image:14.png|center|450px|thumb|B: The fault tree of Figure A using subdiagrams (Transfer gates). The subdiagrams are shown in Figures "C" and "D".|link=]]

[[Image:15.png|center|250px|thumb|C: The fault tree of the robot arm mechanism. This subdiagram is referenced in Figure "B".|link=]]

[[Image:10_16.png|center|400px|thumb|D: The fault tree for the arm jams/collides event. This subdiagram is referenced in Figure "B". It also includes a subdiagram continuation to Figure "E".|link=]]

[[Image:10_17.png|center|400px|thumb|E: The brake shutdown event referenced from Figure "D". it also includes a subdiagram continuation to Figure "F".|link=]]

[[Image:10_18.png|center|350px|thumb|F: The watchdog ESD fails event referenced from Figure "F". It also includes a subdiagram continuation to Figure "G".|link=]]

[[Image:10_19.png|center|400px|thumb|G: The communication fails event referenced from Figure "F".|link=]]

The RBD representation of the fault tree shown in the first figure is given in Figure "H". This same RBD could have been represented using subdiagrams, as shown in Figure "I". In this figure, which is the RBD representation of Figure "B", the subdiagrams in the RBD link to the fault trees of Figures "D" and "C" and their sub-trees.

[[Image:10_20.png|center|500px|thumb|H: This is the RBD equivalent of the complete fault tree of Figure "A".|link=]]

[[Image:10_21.png|center|350px|thumb|I: The RBD representation of Figure "B" with the subdiagrams in the RBD linked to the fault trees of Figures "C" and "D" and their sub-trees.|link=]]

===XOR Gate===

[[Image:16.png|center|100px|link=]]

In an XOR gate, the output event occurs if exactly one input event occurs. This is similar to an OR gate with the exception that if more than one input event occurs then the output event does not occur. For example, if there are two input events then the XOR gate indicates that the output event occurs if only one of the input events occurs but not if zero or both of these events occur. From a system reliability perspective, this would imply that a two-component system would function even if both components had failed. Furthermore, when dealing with time-varying failure distributions, and if system components do not operate through failure, a failure occurrence of both components at the exact same time ( <math>dt)\,\!</math> is an unreachable state; thus an OR gate would suffice. For these reasons, an RBD equivalent of an XOR gate is not presented here and BlockSim does not explicitly provide an XOR gate.

=Event Classifications=
Traditional fault trees use different shapes to represent different events. Unlike gates, however, different events in a fault tree are not treated differently from an analytical perspective. Rather, the event shapes are used to convey additional information visually. BlockSim includes some of the main event symbols from classical fault tree analysis and provides utilities for changing the graphical look of a block to illustrate a different type of event. Some of these event classifications are given next. From a properties perspective, all events defined in BlockSim can have fixed probabilities, failure distributions, repair distributions, crews, spares, etc. In other words, fault tree event blocks can have all the properties that an RBD block can have. This is an enhancement and a significant expansion over traditional fault trees, which generally include just a fixed probability of occurrence and/or a constant failure rate.

===Basic Event===

[[Image:5.png|center|100px|link=]]

A basic event (or failure event) is identical to an RBD block and has been traditionally represented by a circle.

===Undeveloped Event===

[[Image:diamond.png|center|100px|link=]]

An undeveloped event has the same properties as a basic event with the exception that it is graphically rendered as a diamond. The diamond representation graphically illustrates that this event could have been expanded into a separate fault tree but was not. In other words, the analyst uses a different symbol to convey that the event could have been developed (broken down) further but he/she has chosen not to do so for the analysis.

===Trigger Event===
[[Image:pentagon.png|center|100px|link=]]

A trigger event is an event that can be set to occur or not occur (i.e., it usually has a fixed probability of 0 or 1). It is usually used to turn paths on or off or to make paths of a tree functional or non-functional. Furthermore, the terms failed house and working house have been used to signify probabilities of 0 and 1 respectively. In BlockSim, a house shape is available for an event and a house-shaped event has the same properties as a basic event, keeping in mind that an event can be set to Cannot Fail or Failed from the block properties window.

===Conditional Event===
[[Image:oval.png|center|100px|link=]]

A conditional event is represented by an ellipse and specifies a condition. Again, it has all the properties of a basic event. It can be applied to any gate. As an example, event <math>C\,\!</math> in the first figure below would be the conditional event and it would be represented more applicably by an ellipse than a circle, as shown in the second figure below.

[[Image:10.10.png|center|200px|Using an AND gate to represent an inhibit relationship.|link=]]

[[Image:10.22.png|center|200px|Using an ellipse attached to an inhubit gate (with no gate properties) to show the conditional event. This is mathematically equivalent to figure above.|link=]]

=Comparing Fault Trees and RBDs=
The most fundamental difference between fault tree diagrams and reliability block diagrams is that you work in the success space in an RBD while you work in the failure space in a fault tree. In other words, the RBD considers success combinations while the fault tree considers failure combinations. In addition, fault trees have traditionally been used to analyze fixed probabilities (i.e., each event that comprises the tree has a fixed probability of occurring) while RBDs may include time-varying distributions for the success (reliability equation) and other properties, such as repair/restoration distributions. In general (and with some specific exceptions), a fault tree can be easily converted to an RBD. However, it is generally more difficult to convert an RBD into a fault tree, especially if one allows for highly complex configurations.

As you can see from the discussion to this point, an RBD equivalent exists for most of the constructs that are supported by classical fault tree analysis. With these constructs, you can perform the same powerful system analysis, including simulation, regardless of how you choose to represent the system thus erasing the distinction between fault trees and reliability block diagrams.

{{:Same Example Modeled with RBDs or Fault Trees}}

=Using Mirrored Blocks to Represent Complex RBDs as FTDs=
A fault tree cannot normally represent a complex RBD. As an example, consider the RBD shown in the figure below.

[[Image:10.41.png|center|400px|A complex RBD that cannot be represented by a fault tree unless duplicate events are utilized.|link=]]

A fault tree representation for this RBD is:

[[Image:10.42.png|center|350px|A fault tree representation using mirrored blocks (events) of the complex RBD.|link=]]

Note that the same event is used more than once in the fault tree diagram. To correctly analyze this, the duplicate events need to be set up as "mirrored" events to the parent event. In other words, the same event is represented in two locations in the fault tree diagram. It should be pointed out that the RBD in the following figure is also equivalent to the RBD shown earlier and the fault tree of the figure shown above.

[[Image:10.43.png|center|550px|An RBD using mirrored blocks that is equivalent to both the RBD and FTD.|link=]]

=Fault Trees and Simulation=

The slightly modified constructs in BlockSim erase the distinction between RBDs and fault trees. Given this, any analysis that is possible in a BlockSim RBD (including [[Additional_Analyses#Throughput_Analysis|throughput analysis]]) is also available when using fault trees.
<br>

As an example, consider the RBD shown in the first figure below and its equivalent fault tree representation, as shown in the second figure.

[[Image:10.44.png|center|450px|RBD for a repairable system.|link=]]

[[Image:10.45.png|center|450px|Fault tree equivalent of the repairable system shown in figure above.|link=]]

Furthermore, assume the following basic failure and repair properties for each block and event:

:*Block ''A'':
::o Failure Distribution: Weibull; <math>\beta = 1/5\,\!</math>; <math>\eta = 1,000\,\!</math>.
::o Corrective Distribution: Weibull; <math>\beta = 1.5 \,\!</math> ; <math>\eta = 100\,\!</math>.
:*Block ''B'':
::o Failure Distribution: Exponential; <math>\mu = 10,000 \,\!</math>.
::o Corrective Distribution: Weibull; <math>\beta = 1.5 \,\!</math>; <math>\eta = 20\,\!</math>.
:*Block ''C'':
::o Failure Distribution: Normal; <math>\mu = 1,000\,\!</math>; <math>\sigma = 200\,\!</math>.
::o Corrective Distribution: Normal; <math>\mu = 6\,\!</math>; <math>\sigma = 2\,\!</math>.
:*Block ''D'':
::o Failure Distribution: Weibull; <math>\beta = 1.5\,\!</math>; <math>\eta = 10,000\,\!</math>.
::o Corrective Distribution: Exponential; <math>\mu = 10\,\!</math>.
:*Block ''E'':
::o Failure Distribution: Weibull; <math>\beta = 3\,\!</math>; <math>\eta = 1,000\,\!</math>.
::o Corrective Distribution: Weibull; <math>\beta = 1.5\,\!</math>; <math>\eta = 20\,\!</math>.
:*Block ''F'':
::o Failure Distribution: Weibull; <math>\beta = 1.5\,\!</math>; <math>\eta = 5,000\,\!</math>.
::o Corrective Distribution: Weibull; <math>\beta = 1.5\,\!</math>; <math>\eta = 100\,\!</math>.
:*Block ''G'':
::o Failure Distribution: Exponential; <math>\mu = 100,000\,\!</math>.
::o Corrective Distribution: Weibull; <math>\beta = 1.5\,\!</math>; <math>\eta = 10\,\!</math>.
:*Block ''H'':
::o Failure Distribution: Normal; <math>\mu = 5,000\,\!</math>; <math>\sigma = 50\,\!</math>.
::o Corrective Distribution: Normal; <math>\mu = 10\,\!</math>; <math>\sigma = 2\,\!</math>.

A sample table of simulation results is given next for up to <math>t=1,000\,\!</math>, using <math>2,000\,\!</math> simulations for each diagram and an identical seed.

[[Image:FT and RBD example1.png|center|400px|link=|]]

As expected, the results are equivalent (within an expected difference due to simulation) regardless of the diagram type used. It should be pointed out that even though the same seed was used by both diagrams, the results are not always expected to be identical because the order in which the blocks are read from a fault tree diagram during the simulation may differ from the order in which they are read in the RBD; thus using a different random number stream for each block (e.g., block ''G'' in the RBD may receive a different sequence of random numbers than event block ''G'' in the FT).

=Additional Fault Tree Topics=

===Minimal Cut Sets===

Traditional solution of fault trees involves the determination of so-called ''minimal cut sets''. Minimal cut sets are all the unique combinations of component failures that can cause system failure. Specifically, a cut set is said to be a minimal cut set if, when any basic event is removed from the set, the remaining events collectively are no longer a cut set, as discussed in Kececioglu [[Appendix_B:_References | [10]]]. As an example, consider the fault tree shown in the figure below. The system will fail if {1, 2, 3 and 4 fail} or {1, 2 and 3 fail} or {1, 2 and 4 fail}.

[[Image:9.png|center|250px|Minimal cut set example.|link=]]

All of these are cut sets. However, the one including all components is not a minimal cut set because, if 3 and 4 are removed, the remaining events are also a cut set. Therefore, the minimal cut sets for this configuration are {1, 2 , 3} or {1, 2, 4}. This may be more evident by examining the RBD equivalent of the figure above, as shown in the figure below.

[[Image:BS10.png|center|350px|RBD of the fault tree shown in figure above.|link=]]

BlockSim does not use the cut sets methodology when analyzing fault trees. However, interested users can obtain these cut sets for both fault trees and block diagrams with the command available in the Analysis Ribbon.