View source for Crow Extended

{{template:RGA BOOK|3.3|Crow Extended}}
In reliability growth analysis, the [[Crow-AMSAA (NHPP)|Crow-AMSAA (NHPP) model]] assumes that the corrective actions for the observed failure modes are incorporated during the test (test-fix-test). However, in actual practice, fixes may be delayed until after the completion of the test (test-find-test) or some fixes may be implemented during the test while others are delayed (test-fix-find-test). At the end of a test phase, two reliability estimates are of concern: ''demonstrated reliability'' and ''projected reliability''. The demonstrated reliability, which is based on data generated during the test phase, is an estimate of the system reliability for its configuration at the end of the test phase. The projected reliability measures the impact of the delayed fixes at the end of the current test phase.
<br>

Most of the reliability growth literature are concerned with procedures and models for calculating the demonstrated reliability, and very little attention has been paid to techniques for reliability projections. The procedure for making reliability projections utilizes engineering assessments of the effectiveness of the delayed fixes for each observed failure mode. These effectiveness factors are then used with the data generated during the test phase to obtain a projected estimate for the updated configuration by adjusting the number of failures observed during the test phase. The process of estimating the projected reliability is accomplished using the Crow Extended model. The Crow Extended model allows for a flexible growth strategy that can include corrective actions performed during the test, as well as delayed corrective actions. The test-find-test and test-fix-find-test scenarios are simply subsets of the Crow Extended model.

For developmental testing, the Crow Extended model can be applied when using any of the following [[RGA_Data_Types|data types]]:

*Failure Times Data
*Multiple Systems (Known Operating Times)
*Multiple Systems (Concurrent Operating Times)
*Multiple Systems with Dates
*Multiple Systems with Event Codes
*Grouped Failure Times
*Mixed Data

As the name implies, Crow Extended is simply an "extension" of the Crow-AMSAA (NHPP) model. The calculations for Crow Extended still incorporate the methods for Crow-AMSAA based on the data type, as described on the [[Crow-AMSAA (NHPP)]] page. The Crow-AMSAA model estimates the growth during the test, while the Crow Extended model accounts for the growth after the test based on the delayed corrective actions. Additional details regarding the calculations for the Crow Extended model are presented in the sections below.

==Background==
When a system is tested and failure modes are observed, management can make one of two possible decisions: to fix or to not fix the failure modes. Failure modes that are not fixed are called ''A modes'' and failure modes that receive a corrective action are called ''B modes''. The A modes account for all failure modes that management considers to be not economical or not justified to receive corrective action. The B modes provide the assessment and management metric structure for corrective actions during and after a test. There are two types of B modes: BC modes, which are modes that are corrected during the test, and BD modes, which are modes that are corrected only at the end of the test. The management strategy is defined by how the corrective actions, if any, will be implemented. In summary, the classifications are defined as follows:

*'''A''' indicates that no corrective action was performed or will be performed (management chooses not to address for technical, financial or other reasons).

*'''BC''' indicates that the corrective action was implemented during the test. The analysis assumes that the effect of the corrective action was experienced during the test (as with other test-fix-test reliability growth analyses).

*'''BD''' indicates that the corrective action will be delayed until after the completion of the current test. BD modes will provide a jump in the system's MTBF at the termination time. 

In terms of assessing a system's reliability, there are three specific metrics of interest:

*'''Demonstrated (or achieved) MTBF (DMTBF)''' - is the system's instantaneous MTBF at the termination time.
*'''Projected MTBF (PMTBF)''' - is the system's expected instantaneous MTBF after the implementation of the delayed corrective actions.
*'''Growth Potential MTBF (GPMTBF)''' - is the maximum MTBF that can be attained for the system design and management strategy.

These metrics can also be displayed in RGA in terms of failure intensity (FI). The demonstrated MTBF is calculated using basically the same methods, depending on data type, as presented on the [[Crow-AMSAA (NHPP)]] page. Projected MTBF/FI and growth potential MTBF/FI are presented in detail in the sections below.

The following picture shows an example of data entered for the Crow Extended model.

[[Image:rga9.1.png|center|500px|Failure times data for a single system in cumulative format, including classification and mode information.]]
 
As you can see, each failure is indicated with A, BC or BD in the '''Classification''' column. In addition, any number or text can be used to specify the mode. In this example, numbers were used in the '''Mode''' column for simplicity, but you could just as easily use Seal Leak, or whatever designation you deem appropriate for identifying the failure mode. In RGA, a failure mode is defined as a problem and a cause.

Reliability growth is achieved by decreasing the failure intensity. The failure intensity for the A failure modes will not change; therefore, reliability growth can only be achieved by decreasing the BC and BD mode failure intensity. In general, the only part of the BD mode failure intensity that can be decreased is that which has been seen during testing, since the failure intensity due to BD modes that were unseen during testing still remains. The BC failure modes are corrected during test and the BC failure intensity will not change any more at the end of test.

It is very important to note that once a BD failure mode is in the system, it is rarely totally eliminated by a corrective action. After a BD mode has been found and fixed, a certain percentage of the failure intensity will be removed, but a certain percentage of the failure intensity will generally remain. For each BD mode, an ''effectiveness factor'' (EF) is required to estimate how effective the corrective action will be in eliminating the failure intensity due to the failure mode. The EF is the fractional decrease in a mode's failure intensity after a corrective action has been made, and it must be a value between 0 and 1. A study on EFs showed that an average EF, <math>d\,\!</math>, is about 70%. Therefore, about 30 percent, (i.e., 100 <math>(1-d)\,\!</math> percent), of the BD mode failure intensity will typically remain in the system after all of the corrective actions have been implemented. However, individual EFs for the failure modes may be larger or smaller than the average. The next figure displays the RGA software's Effectiveness Factor window where the effectiveness factors for each unique BD failure mode can be specified.

[[Image:rga9.2.png|center|400px|Effectiveness factors defined for each unique BD mode.]]

==Test-Find-Test==<!-- THIS SECTION HEADER IS LINKED FROM ANOTHER SECTION IN THIS PAGE. IF YOU RENAME THE SECTION, YOU MUST UPDATE THE LINK(S). -->
Test-find-test is a testing strategy where all corrective actions are delayed until after the test. Therefore, there are not any BC modes when analyzing test-find-test data (only A and BD modes). This scenario is also called the ''Crow-AMSAA Projection'' model, but for the purposes of the RGA software, it is simply a special case of the Crow Extended model.

Since there are no fixes applied during the test, the assumption is that the system's MTBF does not change during the test. In other words, the system's MTBF is constant. The system should not be exhibiting an increasing or decreasing trend in its reliability if changes are not being made. Therefore, the assumption is that <math>\beta = 1\,\!</math>. RGA will return two <math>\beta\,\!</math> values; Beta (hyp) which always shows a value equal to 1 since this is the underlying assumption, and Beta which is the Crow-AMSAA (NHPP) estimate that considers all of the failure times. The assumption of <math>\beta = 1\,\!</math> can be verified by looking at the confidence bounds on <math>\beta\,\!</math>. If the confidence bounds on <math>\beta\,\!</math> include one, then you can fail to reject the hypothesis that <math>\beta = 1\,\!</math>. RGA does this check automatically and uses a confidence level equal to 1 minus the specified significance level to check if the confidence bounds on <math>\beta\,\!</math> include one. If the <math>\beta = 1\,\!</math> assumption is violated, then the value for Beta (hyp) will be displayed in red text. If the confidence bounds on <math>\beta\,\!</math> do not include 1, then the following questions should be considered as they relate to the data:

*If multiple systems were tested, did they have the same configuration throughout the test? Were the corrective actions applied to all systems?
*Were the test conditions consistent for each system?
*Was there a change in the failure definition?
*Any issues with data entry?

<math>\beta = 1\,\!</math> is then used to estimate the demonstrated MTBF of the system and it is also used in the goodness-of-fit tests.

===Projected Failure Intensity===
Suppose a system is subjected to development testing for a period of time, <math>T\,\!</math>. The system can be considered as consisting of two types of failure modes: A modes and BD modes. It is assumed that all BD modes are in series and fail independently according to the exponential distribution. Also assume that the rate of occurrence of A modes follows an exponential distribution with failure intensity <math>{{\lambda }_{A}}\,\!</math>. The system MTBF is constant throughout the test phase since all of the corrective actions are delayed until after the completion of the test. After the delayed fixes have been implemented, the system MTBF will then jump to a higher value.

Let <math>K\,\!</math> denote the total number of BD modes in the system, and let <math>{{\lambda }_{i}}\,\!</math> denote the failure intensity for the <math>{{i}^{th}}\,\!</math> BD mode, such that <math>i = 1,2,\ldots ,K\,\!</math>. Then, at time equal to zero, the system failure intensity <math>r(0)\,\!</math> is:

:<math>\begin{align}
r(0)={{\lambda }_{A}}+{{\lambda }_{BD}}
\end{align}\,\!</math>

where:  
:<math>{{\lambda }_{BD}}=\underset{i=1}{\overset{K}{\mathop{\sum }}}\,{{\lambda }_{i}}\,\!</math>.

During the test <math>(0,T)\,\!</math>, a random number of <math>M\,\!</math> distinct BD modes will be observed, such that <math>M\le K\,\!</math>. Denote the effectiveness factor (EF) for the <math>{{i}^{th}}\,\!</math> BD mode as <math>{{d}_{i}}\,\!</math>, <math>i = 1,2,\ldots ,K\,\!</math>. The effectiveness factor <math>{{d}_{i}}\,\!</math> is the percent decrease in <math>{{\lambda }_{i}}\,\!</math> after a corrective action has been made for the <math>{{i}^{th}}\,\!</math> BD mode. That is, the corrective action for the <math>{{i}^{th}}\,\!</math> BD mode removes <math>100\times {{d}_{i}}\,\!</math> percent of the failure rate, and <math>100\times (1-{{d}_{i}})\,\!</math> percent remains. The failure intensity for the <math>{{i}^{th}}\,\!</math> BD failure mode after a corrective action is <math>(1-{{d}_{i}}){{\lambda }_{i}}\,\!</math>. If corrective actions are taken on the <math>M\,\!</math> BD modes observed by time <math>T\,\!</math>, then the system failure intensity is reduced from <math>r(0)\,\!</math> to:

:<math>\begin{align}
  r\left( T \right)  = & {{\lambda }_{A}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,\left( 1-{{d}_{i}} \right){{\lambda }_{i}}+({{\lambda }_{BD}}-\underset{i=1}{\overset{M}{\mathop \sum }}\,{{\lambda }_{i}}) \\ 
  = & {{\lambda }_{A}}+{{\lambda }_{BD}}-\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}{{\lambda }_{i}}  
\end{align}\,\!</math>

where:

*<math>\underset{i=1}{\overset{M}{\mathop{\sum }}}\,(1-{{d}_{i}}){{\lambda }_{i}}\,\!</math> is the failure intensity for the <math>M\,\!</math> modes after the corrective actions
*<math>({{\lambda }_{BD}}-\underset{i=1}{\overset{M}{\mathop{\sum }}}\,{{\lambda }_{i}})\,\!</math> is the remaining failure intensity for all unseen BD modes

All <math>M\,\!</math> BD modes observed by test time <math>T\,\!</math> may not be fixed by time <math>T\,\!</math> so the actual failure intensity at time <math>T\,\!</math> may not be <math>r(T)\,\!</math>. However, <math>r(T)\,\!</math> can be viewed as the achieved failure intensity at time <math>T\,\!</math> if all fixes were updated and incorporated into the system. All of the fixes for the BD modes found during the test are incorporated as delayed fixes at the end of the test phase. Therefore, the system failure intensity is constant at <math>r(0)={{\lambda }_{A}}+{{\lambda }_{BD}}\,\!</math> through the test phase and will then jump to a lower value <math>r(T)\,\!</math> after the delayed fixes have been implemented. Let <math>{{N}_{A}}\,\!</math> and <math>{{N}_{BD}}\,\!</math> be the total number of A and BD failures observed during the test <math>(0,T)\,\!</math> and let <math>N={{N}_{A}}+{{N}_{BD}}\,\!</math>. In addition, there are <math>M\,\!</math> distinct BD modes observed during the test. After implementing the <math>M\,\!</math> fixes, the failure intensity for the system at time <math>T\,\!</math> (after the jump) is given by the function <math>r(T)\,\!</math>.

<math>r(0)\,\!</math> is actually the demonstrated failure intensity, which is based on actual system performance of the hardware tested and not of some future configuration. A demonstrated reliability value should be determined at the end of each test phase. The demonstrated failure intensity is:  

:<math>{{\hat{\lambda }}_{D}}(T)=r(0)=\frac{{{N}_{A}}+{{N}_{BD}}}{T}\,\!</math>

The demonstrated MTBF is given by: 

:<math>\widehat{{MTBF}_{D}}={{[{{\hat{\lambda }}_{D}}(T)]}^{-1}}\,\!</math>

The detailed procedure for estimating <math>r(T)\,\!</math> is given in Crow [[RGA_References|[20]]] and is reviewed here.

Let <math>E[\cdot ]\,\!</math> denote the expected value:

:<math>E[r(T)]={{\lambda }_{A}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}{{\lambda }_{i}}{{e}^{-{{\lambda }_{i}}T}}\,\!</math>

Under realistic assumptions, <math>E[r(T)]\,\!</math> also may be expressed as: 

:<math>E[r(T)]={{\lambda }_{A}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}+\overline{d}h(T)\,\!</math>

where <math>\overline{d}\,\!</math> is the mean effectiveness factor and <math>h(T)\,\!</math> is the instantaneous rate at which a new BD mode will occur at time <math>T\,\!</math>. <math>\overline{d}h(T)\,\!</math> is the bias term (or sometimes called the 3<sup>rd</sup> term), such that: 

:<math>B(T)=\overline{d}h(T)\,\!</math>

The mean <math>\overline{d}\,\!</math> is given by: 

:<math>\overline{d}=\frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}\,\!</math>

Therefore, the projected failure intensity <math>r(T)\,\!</math> is then estimated at the end of the test phase by: 

:<math>\hat{r}(T)=\left( \frac{{{N}_{A}}}{T}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T} \right)+\overline{d}h(T)\,\!</math>

The projected MTBF is:

:<math>\widehat{{MTBF}_{P}}={{[r(T)]}^{-1}}\,\!</math>

====Mathematical Formulation====
As indicated previously, the failure intensity of the system at <math>t=0\,\!</math> is given by:

:<math>\begin{align}
    {{\lambda }_{System}}= & {{\lambda }_{A}}+{{\lambda }_{BD}} \\
    = & {{\lambda }_{A}}+{{\lambda }_{B{{D}_{Seen}}}}+{{\lambda }_{B{{D}_{Unseen}}}}
\end{align}\,\!</math>

The estimate for the projected failure intensity, after the corrective actions have been implemented, is then:

:<math>\begin{align}
    {{\lambda }_{\Pr ojected}}= &  {{\lambda }_{A}}+\left( 1-d \right)\left( {{\lambda }_{BD}}-h\left( t \right) \right)+h\left( t \right)\\
    = & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-\left( 1-d \right)h\left( t \right)+h\left( t \right)\\
    = & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}-h\left( t \right)+dh\left( t \right)+h\left( t \right)\\
    = & {{\lambda }_{A}}+\left( 1-d \right){{\lambda }_{BD}}+h\left( t \right)
\end{align}\,\!</math>

This is the basic format of the equation for the projected failure intensity for the Crow Extended model for test-find-test.

===h(t) Function===
h(t) is defined as the unseen BD mode failure intensity. It is also defined as the rate at which new unique BD modes are being discovered. The maximum likelihood estimate of <math>h(t)\,\!</math> is calculated using:

:<math>\hat{h}\left( t \right)={{\hat{\lambda }}_{BD}}{{\overline{\beta }}_{BD}}{{t}^{{{{\overline{\beta }}}_{BD}}-1}}\,\!</math>

where <math>{\overline{\beta }_{BD}}\,\!</math> is the unbiased estimate. The unbiased estimate is always used when calculating <math>\hat{h}\left( t \right)\,\!</math>.

The parameters of the <math>h(t)\,\!</math> function, <math>{{\beta }_{BD}}\,\!</math> and <math>{{\lambda }_{BD}}\,\!</math>, are calculated using the first occurrence of each BD mode. In order to have growth, <math>{{\beta }_{BD}}\,\!</math>  must be less than one. If <math>{{\beta }_{BD}}\,\!</math> is close to one then it is possible that the program could be in trouble since this indicates that there are very few repeat occurrences. In this case, each failure tends to be a unique mode. If <math>{{\beta }_{BD}}\,\!</math>  is less than one then the rate at which new unique BD modes are occurring is decreasing.

Let <math>{{X}_{1}}<{{X}_{2}}<\ldots <{{X}_{M}}<T\,\!</math> denote the cumulative test times for the first occurrences of BD modes. Then, the maximum likelihood estimates of <math>{{\lambda }_{BD}}\,\!</math> and <math>{{\beta }_{BD}}\,\!</math> are:

:<math>{{\hat{\beta }}_{BD}}=\frac{M}{\underset{i=1}{\overset{M}{\mathop{\sum }}}\,\ln \left( \tfrac{T}{{{X}_{i}}} \right)}\,\!</math>

The unbiased estimate of <math>{{\beta }_{BD}}\,\!</math> is: 

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

:<math>{{\hat{\lambda }}_{BD}}=\frac{M}{{{T}^{{{{\overline{\beta }}}_{BD}}}}}\,\!</math>

In particular, the maximum likelihood estimate for the rate of occurrence for the distinct BD modes at the termination time, <math>T\,\!</math>, is: 

:<math>\begin{align}
  \hat{h}(T)  = & {{\hat{\lambda }}_{BD}}{{\overline{\beta }}_{BD}}{{T}^{{{\overline{\beta }}_{BD}}-1}} \\ 
  = & \frac{M{{\overline{\beta }}_{BD}}}{T}  
\end{align}\,\!</math>

The parameters associated with <math>h(t)\,\!</math> can be viewed in RGA by selecting '''BD modes''' from the dropdown to the right of '''Results (All Modes)''' in the Results Area on the control panel to the right of the data sheet. The displayed value for the failure intensity, '''FI''', is <math>h(T)\,\!</math>.

===Growth Potential===
Growth Potential, when represented in terms of MTBF, is the maximum system reliability that can be attained for the system design and current management strategy. The maximum MTBF will be attained when all <math>K\,\!</math> BD modes have been observed and fixed with EFs <math>{{d}_{i}}\,\!</math>. If the system is tested long enough then the failures that are observed in this case will be either repeat BD modes or A modes. In other words, there is not another unique BD mode to find within the system and in most cases the growth potential is a value that may never actually be achieved. The growth potential can be thought of as an upper bound on the system's MTBF and ideally, should be about 30% above the system's requirement. As the system's MTBF gets closer to the growth potential, it becomes more difficult to increase the system's MTBF because it is taking more and more test time to propagate the next unique BD mode. The BD modes present opportunities for growth, but the rate of occurrence for unique BD modes goes down due to the decrease in <math>h(t)\,\!</math>. The growth potential is reached when <math>h(t)\,\!</math> is equal to zero. In other words, the difference between the projected failure intensity and the growth potential is <math>h(t)\,\!</math>. At about 2/3 of the growth potential it becomes increasingly difficult to increase the system's MTBF as <math>h(t)\,\!</math> function starts to flatten out.
 
The failure intensity <math>r(T)\,\!</math> will depend on the management strategy that determines the classification of the A and BD failure modes. The engineering effort applied to the corrective actions determines the effectiveness factors. In addition, <math>r(T)\,\!</math> depends on <math>h(t)\,\!</math>, which is the rate at which problem failure modes are being seen during testing. <math>h(t)\,\!</math> drives the opportunity to take corrective actions based on the seen failure modes and it is an important factor in the overall reliability growth rate. The reliability growth potential is the limiting value of <math>r(T)\,\!</math> as <math>T\,\!</math> increases. This limit is the maximum MTBF that can be attained with the current management strategy.  In terms of failure intensity, the growth potential is expressed by the following equation: 

:<math>{{r}_{GP}}={{\lambda }_{A}}+\underset{i=1}{\overset{K}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}\,\!</math>

In terms of the MTBF, the growth potential is given by: 

:<math>\begin{align}
MTB{{F}_{GP}}=1/{{r}_{GP}}
\end{align}\,\!</math>

The procedure for estimating the growth potential is as follows. Suppose that the system is tested for a period of time <math>T\,\!</math> and that <math>N\,\!</math> failures have been observed. According to the management strategy, <math>{{N}_{A}}\,\!</math> of these failures are A modes and <math>{{N}_{BD}}\,\!</math> of these failures are BD modes. For the BD modes, there will be <math>M\,\!</math> distinct fixes. As before, <math>{{N}_{i}}\,\!</math> is the total number of failures for the <math>{{i}^{th}}\,\!</math> BD mode and <math>{{d}_{i}}\,\!</math> is the corresponding assigned EF. From this data, the growth potential failure intensity is estimated by: 

:<math>{{\hat{r}}_{GP}}(T)=\left( \frac{{{N}_{A}}}{T}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T} \right)\,\!</math>

The growth potential MTBF is estimated by: 

:<math>M\hat{T}B{{F}_{GP}}={{[{{\hat{r}}_{GP}}]}^{-1}}\,\!</math>

===Example: Test-Find-Test Data===
{{:Test-Find-Test_Data_Example}}

==Test-Fix-Find-Test==
Traditional reliability growth models provide assessments for two types of testing and corrective action strategies: ''test-fix-test'' and ''test-find-test''. In test-fix-test, failure modes are found during testing and corrective actions for these modes are incorporated during the test. Data from this type of test can be modeled appropriately with the [[Crow-AMSAA (NHPP)|Crow-AMSAA model]]. In test-find-test, modes are found during testing, but all of the corrective actions are delayed and incorporated after the completion of the test. Data from this type of test can be modeled appropriately with the Crow-AMSAA Projection model, which was described above in the [[Crow_Extended#Test-Find-Test|Test-Find-Test section]]. However, a common strategy involves a combination of these two approaches, where some corrective actions are incorporated during the test and some corrective actions are delayed and incorporated at the end of the test. This strategy is referred to as ''test-fix-find-test''. Data from this test can be modeled appropriately with the Crow Extended reliability growth model, which is described next.

Recall that B failure modes are all failure modes that will receive a corrective action. In order to provide the assessment and management metric structure for corrective actions during and after a test, two types of B modes are defined. BC failure modes are corrected during the test and BD failure modes are delayed until the end of the test. Type A failure modes are defined as before; (i.e., those failure modes that will not receive a corrective action, either during or at the end of the test).

===Development of the Crow Extended Model===
Let <math>{{\lambda }_{BD}}\,\!</math> denote the constant failure intensity for the BD failure modes, and let <math>h(t|BD)\,\!</math> denote the first occurrence function for the BD failure modes. In addition, as before, let <math>K\,\!</math> be the number of BD failure modes, let <math>{{d}_{i}}\,\!</math> be the effectiveness factor for the <math>{{i}^{th}}\,\!</math> BD failure mode and let <math>\overline{d}\,\!</math> be the average effectiveness factor.

The Crow Extended model projected failure intensity is given by: 

:<math>{{\lambda }_{EM}}={{\lambda }_{CA}}-{{\lambda }_{BD}}+\underset{i=1}{\overset{K}{\mathop \sum }}\,(1-{{d}_{i}}){{\lambda }_{i}}+\overline{d}h(T|BD)\,\!</math>

where <math>{{\lambda }_{CA}}=\lambda \beta {{T}^{\beta -1}}\,\!</math> is the achieved failure intensity at time <math>T\,\!</math>.

The Crow Extended model projected MTBF is: 

:<math>\begin{align}
{{M}_{EM}}=1/{{\lambda }_{EM}}
\end{align}\,\!</math>

This is the MTBF after the delayed fixes have been implemented. Under the extended reliability growth model, the demonstrated failure intensity before the delayed fixes is the first term, <math>{{\lambda }_{CA}}\,\!</math>. The demonstrated MTBF at time <math>T\,\!</math> before the delayed fixes is given by: 

:<math>{{M}_{CA}}\text{ }={{[{{\lambda }_{CA}}]}^{-1}}\,\!</math>

If you assume that there are no delayed corrective actions (BD modes), then the model reduces to a special case of the Crow-AMSAA model where the achieved MTBF equals the projection, <math>\lambda_{CA}\,\!</math>. That is, there is no jump. If you assume that there are no corrective actions during the test (BC modes) then the model reduces to the test-find-test scenario described in the previous section. 

===Estimation of the Model===
In the general estimation of the Crow Extended model, it is required that all failure times during the test are known. Furthermore, the ID of each A, BC and BD failure mode needs to be entered.

The estimate of the projected failure intensity for the Crow Extended model is given by: 

:<math>{{\widehat{\lambda }}_{EM}}={{\widehat{\lambda }}_{CA}}-{{\widehat{\lambda }}_{BD}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T}+\overline{d}\widehat{h}(T|BD)\,\!</math>

where <math>{{N}_{i}}\,\!</math> is the total number of failures for the <math>{{i}^{th}}\,\!</math> BD mode and <math>{{d}_{i}}\,\!</math> is the corresponding assigned EF. In order to obtain the first term, <math>{{\widehat{\lambda }}_{CA}}\,\!</math>, fit all of the data (regardless of mode classification) to the Crow-AMSAA model to estimate <math>\widehat{\beta }\,\!</math> and <math>\widehat{\lambda }\,\!</math>, thus:

:<math>{{\widehat{\lambda }}_{CA}}=\widehat{\lambda }\widehat{\beta }{{T}^{\widehat{\beta }-1}}\,\!</math>

The remaining terms are analyzed with the Crow Extended model, which is applied only to the BD data. 

:<math>{{\widehat{\lambda }}_{BD}}=\frac{{{N}_{BD}}}{T}\,\!</math>
:<math>\begin{align}
  \widehat{h}(T|BD)  = & {{\widehat{\lambda }}_{BD}}{{\widehat{\beta }}_{BD}}{{T}^{{{\widehat{\beta }}_{BD}}-1}} \\ 
  = & \frac{M{{\widehat{\beta }}_{BD}}}{T}  
\end{align}\,\!</math>

<math>{{\widehat{\beta }}_{BD}}\,\!</math> is the unbiased estimated of <math>\beta \,\!</math> for the Crow-AMSAA model based on the first occurrence of <math>M\,\!</math> distinct BD modes. 

The structure for the Crow Extended model includes the following special data analysis cases:

#Test-fix-test with no failure modes known or with BC failure modes known. With this type of data, the Crow Extended model will take the form of the [[Crow-AMSAA (NHPP)|traditional Crow-AMSAA analysis]].
#Test-find-test with BD failure modes known. With this type of data, the Crow Extended model will take the form of the Crow-AMSAA Projection analysis described previously in the [[Crow_Extended#Test-Find-Test|Test-Find-Test section]].
#Test-fix-find-test with BC and BD failure modes known. With this type of data, the full capabilities of the Crow Extended model will be applied, as described in the following sections.

===Reliability Growth Potential and Maturity Metrics===
The growth potential and some maturity metrics for the Crow Extended model are calculated as follows.

*Initial system MTBF and failure intensity are given by: 
	
:<math>{{\widehat{M}}_{I}}=\frac{\Gamma \left( 1+\tfrac{1}{\widehat{\beta }} \right)}{{{\widehat{\lambda }}^{\tfrac{1}{\widehat{\beta }}}}}\,\!</math>
	
and:
	
:<math>{{\widehat{\lambda }}_{I}}={{[{{\widehat{M}}_{I}}]}^{-1}}\,\!</math>
	
where <math>\widehat{\beta }\,\!</math> and <math>\widehat{\lambda }\,\!</math> are the estimators of the Crow-AMSAA model for all data regardless of the failure mode classification (i.e., A, BC or BD).

*The A mode failure intensity and MTBF are given by:
	
:<math>{{\widehat{\lambda }}_{A}}=\frac{{{N}_{A}}}{T}\,\!</math>		
:<math>{{\widehat{M}}_{A}}={{[{{\widehat{\lambda }}_{A}}]}^{-1}}\,\!</math>	

*The Initial BD mode failure intensity is given by: 
	
:<math>{{\widehat{\lambda }}_{BD}}=\frac{{{N}_{BD}}}{T}\,\!</math>	
	
*The BC mode initial failure intensity and MTBF are given by:
	
:<math>{{\widehat{\lambda }}_{I(BC)}}={{\widehat{\lambda }}_{I}}-{{\widehat{\lambda }}_{A}}-{{\widehat{\lambda }}_{BD}}\,\!</math>
:<math>{{\widehat{M}}_{I(BC)}}={{[{{\widehat{\lambda }}_{I(BC)}}]}^{-1}}\,\!</math>

*Failure intensity <math>h(T|BC)\,\!</math> and instantaneous MTBF <math>M(T|BC)\,\!</math> for new BC failure modes at the end of test time <math>T\,\!</math> are given by:

:<math>\widehat{h}(T|BC)=\widehat{\lambda }\widehat{\beta }{{T}^{\widehat{\beta }-1}}\,\!</math>
:<math>\widehat{M}(T|BC)={{[\widehat{h}(T|BC)]}^{-1}}\,\!</math>

where <math>\widehat{\beta }\,\!</math> and <math>\widehat{\lambda }\,\!</math> are the estimators of the Crow-AMSAA model for the first occurrence of distinct BC modes.

*Average effectiveness factor for BC failure modes is given by:
	
:<math>{{\widehat{d}}_{BC}}=\frac{\left[ \tfrac{N_{BC}^{\left( \tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)}}{\Gamma \left( 1+\tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)} \right]-{{N}_{BC}}}{\left[ \tfrac{N_{BC}^{\left( \tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)}}{\Gamma \left( 1+\tfrac{1}{{{{\hat{\beta }}}_{BC}}} \right)} \right]-{{M}_{BC}}}\,\!</math>	
	
:where <math>{{N}_{BC}}\,\!</math> is the total number of observed BC modes, <math>{{M}_{BC}}\,\!</math> is the number of unique BC modes and <math>{{\hat{\beta }}_{BC}}\,\!</math> is the MLE for the first occurrence of distinct BC modes. If <math>{{\hat{\beta }}_{BC}}\ge 1\,\!</math> then <math>{{\widehat{d}}_{BC}}\,\!</math> equals zero.

*Growth potential failure intensity and growth potential MTBF are given by:
	
:<math>{{\widehat{\lambda }}_{GP}}={{\widehat{\lambda }}_{CA}}-{{\widehat{\lambda }}_{BD}}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T}\,\!</math>	
	
:<math>{{\widehat{M}}_{GP}}={{[{{\widehat{\lambda }}_{GP}}]}^{-1}}\,\!</math>

===Failure Mode Management Strategy===
Management controls the resources for corrective actions. Consequently, the effectiveness factors are part of the management strategy. For the BD mode failure intensity that has been seen during development testing, 100 <math>d\,\!</math> percent will be removed and 100 <math>(1-d)\,\!</math> percent will remain in the system. Therefore, after the corrective actions have been made, the current system instantaneous failure intensity consists of the failure intensity due to the A modes plus the failure intensity for the unseen BC modes, and plus the failure intensity for the unseen BD modes plus the failure intensity for the BD modes that have been seen. The following pie chart shows how the system's instantaneous failure intensity can be broken down into its individual pieces based on the current failure mode strategy.

[[Image:rga9.5.png|center|400px|System failure intensity after the corrective actions.]]

Keep in mind that the individual components of the system's instantaneous failure intensity will depend on the classifications defined in the data. For example, if BC modes are not present within the data, then the BC mode MTBF will not be a part of the overall system MTBF. The individual pieces of the pie, as shown in the above figure, are calculated using the following equations.

Let:

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

where <math>T\,\!</math> is the test time and <math>\hat{\beta }\,\!</math> and <math>\hat{\lambda }\,\!</math> are the maximum likelihood estimates of the Crow-AMSAA model for all of the data. <math>\hat{\beta }\,\!</math> is the biased estimate of <math>\beta \,\!</math>. Therefore:

:<math>\hat{\beta }=\frac{N}{\underset{i=1}{\overset{N}{\mathop{\sum }}}\,\ln \left( \tfrac{T}{{{X}_{i}}} \right)}\,\!</math>
:<math>\hat{\lambda }=\frac{N}{{{T}^{{\hat{\beta }}}}}\,\!</math>

where <math>N\,\!</math> is the total number of failures, and <math>{{X}_{i}}\,\!</math> is the <math>{{i}^{th}}\,\!</math> time-to-failure. Let the successive failures <math>0<{{X}_{1}}<{{X}_{2}}<\ldots <{{X}_{3}}<{{X}_{N}}\,\!</math> be partitioned into the A mode failures ( <math>{{N}_{A}}\,\!</math> ), BC first occurrence failures ( <math>{{N}_{BCF}}\,\!</math> ), BC remaining failures ( <math>{{N}_{BCR}}\,\!</math> ), BD first occurrence failure ( <math>{{N}_{BDF}}\,\!</math> ) and the BD remaining failures ( <math>{{N}_{BDR}}\,\!</math> ). For continuous data, each portion of the pie chart, due to each of the modes, is calculated as follows:

*A modes 
	
:<math>A=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{A}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{Ai}}} \right) \right]\hat{r}(T)\,\!</math>

*BC modes unseen

:<math>B{{C}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BCF}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BCFi}}} \right) \right]\hat{r}(T)\,\!</math>

*BC modes seen

:<math>B{{C}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BCR}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BCRi}}} \right) \right]\hat{r}(T)\,\!</math>

*BD modes unseen

:<math>B{{D}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BDF}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BDFi}}} \right) \right]\hat{r}(T)\,\!</math>

*BD modes seen

:<math>B{{D}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ \underset{i=1}{\overset{{{N}_{BDR}}}{\mathop \sum }}\,\ln \left( \frac{T}{{{X}_{BDRi}}} \right) \right]\hat{r}(T)\,\!</math>

*BD modes remain

:<math>\begin{align}
  B{{D}_{remain}}  = & \left( 1-\frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}} \right)\cdot B{{D}_{seen}} \\ 
  = & \left( 1-\overline{d} \right)\cdot B{{D}_{seen}}  
\end{align}\,\!</math>

*BD modes removed

:<math>\begin{align}
  B{{D}_{removed}} = & \frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}\cdot B{{D}_{seen}} \\ 
 = & \overline{d}\cdot B{{D}_{seen}}  
\end{align}\,\!</math>

For grouped data, the maximum likelihood estimates of <math>\beta \,\!</math> and <math>\lambda \,\!</math> from the [[Crow-AMSAA (NHPP)|Crow-AMSAA (NHPP)]] model are calculated such that the following equations are satisfied:

:<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 \right]=0\,\!</math>

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

where <math>K\,\!</math> is the number of groups and <math>N=\underset{i=1}{\overset{K}{\mathop{\sum }}}\,{{N}_{i}}\,\!</math>.

*A modes 
	
:<math>A=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{A}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{Ai}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BC modes unseen

:<math>B{{C}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BCF}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BCFi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BC modes seen

:<math>B{{C}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BCR}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BCRi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BD modes unseen

:<math>B{{D}_{unseen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BDF}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BDFi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BD modes seen

:<math>B{{D}_{seen}}=\left( \frac{T}{{{N}^{2}}} \right)\left[ {{N}_{BDR}}\ln (T)-\underset{i=1}{\overset{K}{\mathop \sum }}\,\frac{{{N}_{BDRi}}}{{\hat{\beta }}}\left( \frac{t_{i}^{{\hat{\beta }}}\ln (t_{i}^{{\hat{\beta }}})-t_{i-1}^{{\hat{\beta }}}\ln (t_{i-1}^{{\hat{\beta }}})}{t_{i}^{{\hat{\beta }}}-t_{i-1}^{{\hat{\beta }}}}-1 \right) \right]\hat{r}(T)\,\!</math>

*BD modes remain

:<math>\begin{align}
  B{{D}_{remain}}  = & \left( 1-\frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}} \right)\cdot B{{D}_{seen}} \\ 
  = & \left( 1-\overline{d} \right)\cdot B{{D}_{seen}}  
\end{align}\,\!</math>

*BD modes removed

:<math>\begin{align}
  B{{D}_{removed}}  = & \frac{1}{M}\underset{i=1}{\overset{M}{\mathop \sum }}\,{{d}_{i}}\cdot B{{D}_{seen}} \\ 
  = & \overline{d}\cdot B{{D}_{seen}}  
\end{align}\,\!</math>

===Example: Test-Fix-Find-Test Data=== <!-- THIS SECTION HEADER IS LINKED FROM: Operational Mission Profile Testing. IF YOU RENAME THE SECTION, YOU MUST UPDATE THE LINK(S). -->
{{:Test-Fix-Find-Test_Data_Example}}

==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 Extended Confidence Bounds]] chapter for details on how these confidence bounds are calculated. 

===Confidence Bounds Example===
{{:Crow_Extended_Confidence_Bounds_Example}}

===Another Confidence Bounds Example===
{{:Crow_Extended_Confidence_Bounds_Example_2}}

==Grouped Data== <!-- THIS SECTION HEADER IS LINKED FROM: Operational Mission Profile Testing. IF YOU RENAME THE SECTION, YOU MUST UPDATE THE LINK(S). -->

Parameter estimation for grouped data using the Crow Extended model is the same as the procedure used for the traditional [[Crow-AMSAA (NHPP)#Grouped_Data| Crow-AMSAA (NHPP)]] model. The equations used to estimate the parameters of the Crow Extended model are presented next. For test-find-test data, the maximum likelihood estimates of <math>{{\lambda }_{BD}}\,\!</math> and <math>{{\beta }_{BD}}\,\!</math> are calculated using the first occurrences of the BD modes such that:

:<math>\underset{i=1}{\overset{k}{\mathop \sum }}\,{{n}_{i}}\left[ \frac{T_{i}^{\widehat{\beta }}\ln {{T}_{i}}-T_{i-1}^{\widehat{\beta }}\ln {{T}_{i-

1}}}{T_{i}^{\widehat{\beta }}-T_{i-1}^{\widehat{\beta }}}-\ln {{T}_{k}} \right]=0\,\!</math>

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

where <math>{{n}_{i}}\,\!</math> is the number of distinct BD modes within the <math>{{i}^{th}}\,\!</math> interval. For test-fix-find-test data, the maximum likelihood estimates of <math>{{\lambda }_{BC}}\,\!</math> and <math>{{\beta }_{BC}}\,\!</math> are estimated in the same manner using the first occurrences of the BC modes.

===Confidence Bounds for Grouped Data===
*'''Parameters:''' The confidence bounds on the parameters for the Crow Extended model for grouped data are calculated using the same procedure presented in the [[Crow-AMSAA_Confidence_Bounds|Crow-AMSAA Confidence Bounds]] chapter. 
*'''Failure Intensity and MTBF:''' 
**If there are no BC modes, the confidence bounds on the demonstrated failure intensity and MTBF, projected failure intensity and MTBF and growth potential failure intensity and MTBF are the same as the procedure presented for [[Crow Extended Confidence Bounds|non-grouped data]]. 
**If there are BC modes, then the confidence bounds on the demonstrated failure intensity and MTBF are the same as the procedure presented in the Crow-AMSAA Confidence Bounds chapter, and the confidence bounds on the projected failure intensity and MTBF and growth potential failure intensity and MTBF are the same as for non-grouped data. 
*'''Time:''' The confidence bounds on time are the same as the procedure presented in the Crow-AMSAA Confidence Bounds chapter.

==Mixed Data==
The Crow Extended model can also be applied to discrete data from one-shot (success/failure) testing. In the RGA software, the '''Discrete Data > Mixed Data''' option creates a data sheet that can accommodate data from tests where a single unit is tested for each successive configuration (individual trial-by-trial), where multiple units are tested for each successive configuration (configurations in groups) or a combination of both. This data sheet can be analyzed with either the Crow-AMSAA (NHPP) model or the Crow Extended model.

For discrete data, corrective actions cannot take place at the time of failure. With that in mind, the mixed data type does not allow for BC modes. For discrete data there are only A or BD modes. In terms of practical applications, think of a growth test for missile systems. Because missiles are one-shot items, any corrective actions applied to the failure modes are delayed until at least the next trial.

Note that for calculation purposes, it is required to have at least three failures in the first interval. If that is not the case, then the data set needs to be grouped before calculating. The RGA software performs this operation in the background.

===Example===
{{:Mixed_Data_-_Crow_Extended_Example}}

==Multiple Systems with Event Codes==

The Multiple Systems with Event Codes data type is used to analyze the failure data from a reliability growth test in which a number of systems are tested concurrently and the implemented fixes are tracked during the test phase. With this data type, all of the systems under test are assumed to have the same system hours at any given time. The Crow Extended model is used for this data type, so all the underlying assumptions regarding the Crow Extended model apply. As such, this data type is applicable only to data from within a single test phase.

As previously presented, the failure mode classifications for the Crow Extended model are defined as follows:

*A indicates that no corrective action was performed or will be performed (management chooses not to address for technical, financial or other reasons).
*BC indicates that the corrective action was implemented during the test. The analysis assumes that the effect of the corrective action was experienced during the test (as with other test-fix-test reliability growth analyses).
*BD indicates that the corrective action will be delayed until after the completion of the current test.

Therefore, implemented fixes can be applied only to BC modes since all BD modes are assumed to be delayed until the end of the test.
For each BC mode, there must be a separate entry in the data set that records the time when the fix was implemented during the test.

===Event Codes===
A Multiple Systems with Event Codes data sheet that is analyzed with the Crow Extended model has an '''Event''' column that allows you to indicate the types of events that occurred during a test phase. The possible event codes that can be used in the analysis are:

'''''I''''': denotes that a certain BC failure mode has been corrected at the specific time; in other words, a fix has been implemented. For this data type, each BC mode must have an associated ''I'' event. The ''I'' event is essentially a timestamp for when the fix was implemented during the test.

'''''Q''''': indicates that the failure was due to a quality issue. An example of this might be a failure caused by a bolt not being tightened down properly. You have the option to decide whether or not to include quality issues in the analysis. This option can be specified by checking or clearing the '''Include Q Events''' check box under Event Code Options on the Analysis tab.

'''''P''''': indicates that the failure was due to a performance issue. You can determine whether or not to include performance issues in the analysis. This option can be specified by checking or clearing the '''Include P Events''' check box under Event Code Options on the Analysis tab.

'''''X''''': indicates that you wish to exclude the data point from the analysis. An ''X'' can be placed in front of any existing event code (e.g., XF to exclude a particular failure time) or entered by itself. The row of data with the ''X'' will not be included in the analysis.

'''''S''''': indicates the system start time. This event code is only selectable in the Normal View.

'''''F''''': indicates a failure time.

'''''E''''': indicates the system end time. This event code is only selectable in the Normal View.

The analysis is based on the equivalent system that combines the operating hours of all the systems. 

===Equivalent Single System===
In order to analyze a Multiple Systems with Event Codes data sheet, the data are converted into a Crow Extended equivalent single system. The implemented fixes (''I'' events) are taken into account when building the equivalent single system from the data for multiple systems.

The basic assumptions and constraints for the use of this data type are listed below:

*Failure modes are assumed to be independent of each other and with respect to the system configuration. The same applies to their related implemented fixes (''I'' events). As such, each mode and its related implemented fixes (''I'' events) are examined separately in terms of their impact to the system configuration.
*If there are BC modes in the data set, there must be at least 3 unique BC modes to analyze the data (together with implemented fixes for each one of them).
*If there are BD modes in the data set, there must be at least 3 unique BD modes to analyze the data.
*To be consistent with the definition of BC modes in the Crow Extended model, every BC mode must have at least one implemented fix (''I'' event) on at least one system.
*Implemented fixes (''I'' events) cannot be delayed to a later phase, because the Crow Extended model applies to a single phase only.

The following list shows the basic rules for calculating the equivalent single system on which the Crow Extended model is applied. Note that the list is not exhaustive since there is an infinite number of scenarios that can occur. These rules cover the most common scenarios. The main concept is to add the time that each system was tested under the same configuration.

# To get to the equivalent single system, each failure time for A modes and BD modes is calculated by adding the time that each system was tested under the same configuration. In practice this means multiplying the failure time in the system by the number of total systems under test. For example, if we have 4 total systems, and system 2 has a BD1 mode at time 30, the BD1 mode failure time in the equivalent single system would be <math>30*4=120\,\!</math>. If system 3 had another BD1 mode at time 40, then that would yield another BD1 mode in the equivalent single system at time <math>40*4=160\,\!</math>. These calculations are done assuming that the start time for the systems are at time zero. If the start time is different than zero, then that time would have to be subtracted from the failure time on each system. For example, if system 1 started at time S=10, and there was a failure at time 30, the equivalent system time would be <math>(30-10)*4=80\,\!</math>.
# Each failure time for a BC mode that occurred before an implemented fix (''I'' event) for that mode is also calculated by multiplying the failure time in the system by the number of total systems in test, as described above.
#The implemented fix (''I'' event) time in the equivalent single system is calculated by adding the test time invested in each system before that ''I'' event takes place. It is the total time that the system has spent at the same configuration in terms of that specific mode.
# If the same BC mode occurs in another system after a fix (''I'' event) has been implemented in one or more systems, the failure time in the equivalent single system is calculated by adding the test time for that BC mode, and one of the following for each of the other systems:
::*If a BC mode occurs in a system that has already seen an ''I'' event for that mode, then you add the time up to the ''I'' event.
:::or
::*If the ''I'' events occurred later than the BC failure time or those systems did not have any ''I'' events for that mode, then you add the time of the BC failure.
:5. If the same BC mode occurs in the same system after a fix (''I'' event) has been implemented in one or more systems, the failure time in the equivalent single system is calculated by adding the test time of each system after that ''I'' event was implemented to the ''I'' event time in the equivalent single system, or zero if an ''I'' event was not present in that system. 

====Example: Equivalent Single System====<!-- THIS SECTION HEADER IS LINKED FROM ANOTHER PLACE IN THIS DOCUMENT. IF YOU RENAME THE SECTION, YOU MUST UPDATE THE LINK(S). -->
{{:Equivalent_System_Example}}

===Transferring Data to an Equivalent Single System===
RGA provides the capability to transfer a Multiple Systems with Event Codes data sheet to various other data types. The following picture shows the available data types that the data sheet can be converted into. When selecting to transfer to an equivalent single system, the data sheet is converted to a Crow Extended - Continuous Evaluation data sheet.

[[Image:rga9.23.png|thumb|center|400px|Transferring the Multiple Systems with Event Codes data sheet to an equivalent single system using the Crow Extended-Continuous Evaluation model.]]

The [[Crow Extended - Continuous Evaluation]] model is designed for analyzing data across multiple test phases, while considering the data for all phases as one data set. Familiarity with this model is necessary for the discussion presented in this section.

When using the Crow Extended - Continuous Evaluation model to transfer the data sheet from Multiple Systems with Event Codes to an equivalent single system, the following rules are used (in addition to the five basic rules presented earlier for calculating the equivalent single system):

*BD modes in the Crow Extended data sheet become BD modes in the equivalent single system of the Crow Extended - Continuous Evaluation data sheet.
*BC modes in the Crow Extended data sheet become BD modes in the equivalent single system of the Crow Extended - Continuous Evaluation data sheet. These BD modes will have associated implemented fixes (''I'' events). Implemented fixes (''I'' events) for BC modes in the Crow Extended data sheet become implemented fixes (''I'' events) for the converted BD modes in the equivalent single system of the Crow Extended - Continuous Evaluation data sheet.
*If an implemented fix (''I'' event) occurred at the same time as the failure, and was implemented at that exact time across all systems, then this becomes a BC mode in the equivalent single system. If the fixes (''I'' events) were not all implemented at the same time or if the fix was not implemented on all systems at the failure time, then this becomes a BD mode in the equivalent single system.

The next figure shows the transferred equivalent single system Crow Extended - Continuous Evaluation data sheet from the Multiple Systems with Event Codes data sheet for the data from the [[Crow_Extended#Example:_Equivalent_Single_System|Equivalent Single System example]] given above.

[[Image:rga9.24.png|thumb|center|400px|The transferred equivalent single system Crow Extended- Continuous Evaluation data sheet from the Multiple Systems with Event Codes data sheet of Figure 9.15.]]

===Iteration Method for Naming Repeated Modes===
When recording modes for transfer from the Multiple Systems with Event Codes to a Crow Extended -Continuous Evaluation equivalent single system, it is recommended to consider using an iteration method to name subsequent recurrences of the same mode. This will help alleviate any issues with the conversion of the definitions of the modes from the Crow Extended model to the Crow Extended - Continuous Evaluation model. For example, if the first occurrence of a mode is BC25, then the second occurrence is suggested to be named as BC25.1. The reasoning behind this recommendation is that in the case that BC25 in the Multiple Systems with Event Codes data sheet has received implemented fixes (''I'' events) at the same time that the failure occurred in all systems, then this mode will be translated as a BC mode in the Crow Extended - Continuous Evaluation equivalent single system. The next recurring failure would also be treated as a BC mode, but in reality it did not have an implemented fix (''I'' event) at the time of failure.

For example, consider the data set shown in the following figure, which represents one system only for simplicity. Notice that the modes BC25, BC35 and BC45 received implemented fixes at the time of failure. Based on that, when they get transferred to the Crow Extended - Continuous Evaluation equivalent single system, they will be considered as BC modes. The subsequent failures of the modes 25, 35 and 45 will also be converted to BC modes, when in reality they had implemented fixes (''I'' events) at a later time.
 
[[Image:rga9.25.png|thumb|center|400px|Repeated modes without iterations.]]

The RGA software will display a warning if you try to convert this data sheet without using iterations.

The next figure shows the same data sheet with the use of iterations for the modes 25, 35 and 45. The subsequent failures are named as BC25.1, BC35.1 and BC45.1.

[[Image:rga9.27.png|thumb|center|400px|Repeated modes with iterations.]]

This way, the conversion to the Crow Extended - Continuous Evaluation model occurs in a valid fashion, because although the original BC modes are converted to BC25, BC35 and BC45, the subsequent failures are converted to BD25.1, BD35.1 and BD45.1 together with their respective implemented fixes (''I'' events). This is shown in the next figure below. Note that the use of iterations is recommended only when transferring to the Crow Extended - Continuous Evaluation equivalent single system; it is not necessary when using the Multiple Systems with Event Codes data sheet that is calculated with the Crow Extended model.

[[Image:rga9.28.png|thumb|center|400px|Correct transfer to the Crow Extended - Continuous Evaluation model with the use of iterations on modes.]]

==More Examples==
===Adjusting the Failure Mode Management Strategy===
{{:Concurrent_Operating_Times_-_Crow_Extended_Example}}

===Estimating the Failure Intensity Remaining After Fixes===
{{:Grouped_Data_-_Crow_Extended_Example}}

===Determining if Design Will Meet MTBF Goal===
{{:Known_Operating_Times_-_Crow_Extended_Example}}