Template:Rga crow extended: Difference between revisions

From ReliaWiki
Jump to navigation Jump to search
(Redirected page to Crow Extended)
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=Crow Extended=
#REDIRECT [[Crow Extended]]
<br>
The most widely used traditional reliability growth tracking model, Crow-AMSAA, was presented in Chapter 5. Using this model for reliability growth analysis 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 has been 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.
<br>
<br>
==Background==
<br>
When a system is tested and failure modes are observed, management can make one of two possible decisions, either to fix or not fix the failure mode. Therefore, the management strategy places failure modes into two categories: A modes and B modes. A modes are all failure modes such that when seen during the test no corrective action will be taken. This accounts for all modes for which management determines that it is not economically or otherwise justified to take 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 modes are corrected during the test and the corrective actions for BD modes are delayed until 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:
<br>
:• 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.
<br>
Figure CrowExtend1 shows an example of data entered for the Crow Extended model.
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 Figure CrowExtend1, 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.
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. It is also clear that, 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. BC failure modes are corrected during test and the BC failure intensity will not change any more at the end of test.
<br>
 
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 you 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 must be a value between 0 and 1. A study on EFs showed that an average EF  <math>d</math>  was about 70 percent. Therefore, typically about 30 percent, i.e. 100 <math>(1-d)</math>  percent, of the BD mode failure intensity will 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. Figure efffact1 displays RGA's Effectiveness Factor window where the effectiveness factors for each unique BD failure mode can be specified.
 
 
[[Image:rga9.1.png|thumb|center|400px|Failure times data for a single system in cumulative format, including classification and mode information.]]
<br>
<br>
[[Image:rga9.2.png|thumb|center|400px|Effectiveness factors defined for each unique BD mode.]]
<br>
 
{{test-find-test rga}}
 
{{test-fix-find-test rga}}
 
{{failure mode management strategy rga}}
 
{{confidence bounds crow extended rga}}
 
==Grouped Data==
 
Parameter estimation for grouped data using the Crow-AMSAA model is the same as described in Chapter 5. 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===
 
The confidence bounds on the parameters for the Crow Extended model for grouped data are calculated using the same as the procedure presented in Chapter 5. 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 in Section 9.5. If there are BC modes, then the confidence bounds on the demonstrated failure intensity and MTBF are the same as the procedure presented in Chapter 5 and the confidence bounds on the projected failure intensity and MTBF and growth potential failure intensity and MTBF are the same as in Section 9.5. The confidence bounds on time are the same as the procedure presented in Chapter 5. 
 
==Mixed Data==
 
The Crow Extended model also can be applied for discrete data from one-shot (success/failure) testing. In RGA, the Discrete Data > Mixed Data option gives 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.
Corrective actions cannot take place at the time of failure for discrete data. 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. Since these are one-shot items, the fixes to 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. RGA performs this operation in the background.
 
 
'''Example 5'''
 
A one-shot system underwent reliability growth testing for a total of 20 trials. The test was performed as a combination of groups of units with the same configuration and individual trials. Table 9.5 shows the obtained data set. The "Failures in Interval" column specifies the number of failures that occurred in each interval and the "Cumulative Trials" column specifies the cumulative number of trials at the end of that interval. In other words, the first three rows contain the data from the first trial, in which 8 units with the same configuration were tested and 3 failures (with different failure modes) were observed. The next row contains data from the second trial, in which 2 units with the same configuration were tested and no failures occurred. And so on.
 
 
{|style= align="center" border="1"
|-
|colspan="4" style="text-align:center"|Table 9.5 - Mixed data for Example 5
|-
!Failures in Interval
!Cumulative Trials
!Classification
!Mode
|-
|1||8||BD||1
|-
|1||8||BD||2
|-
|1||8||BD||3
|-
|0||10
|-
|0||11
|-
|0||12
|-
|1||13||BD||2
|-
|0||14
|-
|0||15
|-
|1||16||BD||4
|-
|0||17
|-
|0||18
|-
|0||18
|-
|1||20||BD||5
|}
 
The table also gives the classifications of the failure modes. There are 5 BD modes. The average effectiveness factor for the BD modes is  <math>0.7</math> . Do the following:
:1) Calculate the demonstrated reliability at the end of the test.
 
:2) Calculate the growth potential reliability.
 
'''Solution'''
 
Based on the equations presented in Chapter 5, the parameters of the Crow-AMSAA (NHPP) model are estimated as follows:
 
 
::<math>\widehat{\beta }=0.8572</math>
 
 
:and:
 
 
::<math>\widehat{\lambda }=0.4602</math>
 
 
However, since there are only A or BD modes for mixed data, there is no growth during the test. In other words, the hypothesis for the  <math>\widehat{\beta }</math>  parameter is that  <math>\widehat{\beta }=1.</math>
From Chapter 5, we know that:
 
 
::<math>\widehat{\lambda }=\frac{n}{T_{n}^{\widehat{\beta }}}</math>
 
 
or, if  <math>\widehat{\beta }=1</math> , this becomes:
 
 
::<math>\begin{align}
  & \widehat{\lambda }= & \frac{n}{{{T}_{n}}} \\
& = & \frac{6}{20} \\
& = & 0.3 
\end{align}</math>
 
 
As we have seen, the Crow-AMSAA 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>
 
 
Using trials instead of time, and accommodating for  <math>\widehat{\beta }=1</math> , we can calculate the instantaneous failure probability at the end of the test, or  <math>T=20</math> :
 
::<math>{{Q}_{i}}(20)=\widehat{\lambda }=0.3</math>
 
 
So the instantaneous reliability at the end of the test, or demonstrated reliability, is:
 
 
::<math>\begin{align}
  & {{R}_{i}}(20)= & 1-{{Q}_{i}}(20) \\
& = & 1-0.3 \\
& = & 0.7 
\end{align}</math>
 
 
Figure mixed Crow Extended folio shows the data sheet of Table 9.5 as calculated in RGA.
Based on Eqn. (extendedGP), the growth potential unreliability is:
 
 
::<math>\begin{align}
  & {{\widehat{Q}}_{GP}}(T)= & \left( \frac{{{N}_{A}}}{T}+\underset{i=1}{\overset{M}{\mathop \sum }}\,(1-{{d}_{i}})\frac{{{N}_{i}}}{T} \right) \\
& = & \underset{i=1}{\overset{M}{\mathop \sum }}\,(1-0.7)\frac{{{N}_{i}}}{T} \\
& = & 0.3*(\frac{1+1+1+1+1+1)}{20} \\
& = & 0.09 
\end{align}</math>
 
 
So the growth potential reliability is:
 
 
::<math>\begin{align}
  & {{\widehat{R}}_{GP}}(T)= & 1-{{\widehat{Q}}_{GP}}(T) \\
& = & 1-0.09 \\
& = & 0.91 
\end{align}</math>
 
 
Figure mixedrowxtendedCP shows the calculation of the growth potential reliability for the mixed data using the QCP in RGA. Figure MixedrowxtendedPlot shows the growth potential plot for this example.
 
 
[[Image:rga9.12.png|thumb|center|400px|Mixed Data calculated with the Crow Extended Model.]]
 
 
[[Image:rga9.13.png|thumb|center|400px|Calculating the gowth potential reliaibility for Crow Extended mixed data using the QCP.]]
 
 
[[Image:rga9.14.png|thumb|center|400px|Growth potential for the Crow Extended mixed data of example 5.]]
<br>
 
==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 only applicable to data within a single test phase.
As previously presented, the failure mode classifications for the Crow Extended model are defined as follows:
<br>
<br>
:• 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.
<br>
Therefore, implemented fixes can only be applied 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.
<br>
<br>
===Event Codes===
The Multiple Systems with Event Codes data type analyzed with the Crow Extended model uses a column to indicate the types of events that occurred during a test phase. Within RGA, event codes are entered within the Event column of the Multiple Systems with Event Codes data sheets. <br>
<br>
The possible event codes that can be used in the analysis are:
<br>
<br>
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.
<br>
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 checkbox under Event Code Options on the Analysis tab.
<br>
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 checkbox under Event Code Options on the Analysis tab.
<br>
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. This row of data will then not be included in the analysis.
<br>
S: indicates the system start time. This event code is only selectable in the Normal View.
<br>
F: indicates a failure time.
<br>
E: indicates the system end time. This event code is only selectable in the Normal View.
<br>
The analysis is based on the equivalent system that combines the operating hours of all the systems. 
<br>
<br>
===Crow Extended 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.
<br>
The basic assumptions and constraints for the use of this data type are listed below:
<br>
<br>
:• 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.
<br>
The following are 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.
<br>
<br>
:1) 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 will 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> .
:2) 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.
:3) 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.
:4) 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:
<br>
:The test time for that BC mode, and one of the following for each of the other systems:
<br>
::a) 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
<br>
::b) 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. 
<br>
<br>
'''Example 6'''
<br>
Consider the data set shown in Figure Simple example Crow Extended ESS. The data sheet needs to be converted to the Crow Extended equivalent single system. This example is used to demonstrate the application of the five rules mentioned above.
 
[[Image:rga9.15.png|thumb|center|400px|Three systems will event codes.]]
<br>
<br>
'''Solution'''
<br>
The first step to create the equivalent single system is to isolate each failure mode and its implemented fixes independently from each other. The numbered items that follow represent an example application for each one of the five rules mentioned above and are presented in the same numbering sequence. 
<br>
:1) Figure ESSD illustrates the application of rule #1 for mode BD1. The mode in the equivalent single system is calculated as  <math>(75+75+75)=225</math>  or  <math>75*3=225.</math>
 
[[Image:rga9.16.png|thumb|center|400px|Calculating a BD mode.]]
<br>
 
Figure 9.16 illustrates the application of rule #1 for mode A110. The mode in the equivalent single system is calculated as
<math>(280+280+280)=840</math>  or  <math>280*3=840.</math>
 
[[Image:rga9.17.png|thumb|center|400px|Calculating an A mode.]]
<br>
<br>
:2) Figure ESSC10 illustrates the application of rule #2 for the first occurrence of the mode BC10 in system 1. The mode in the equivalent single system is calculated as  <math>(150+150+150)=450</math>  or  <math>150*3=450.</math>
 
[[Image:rga9.18.png|thumb|center|400px|Calculating a BC mode that occurred before an implemented fix.]]
<br>
 
:3) Figure ESSBC10 illustrates the application of rule #3 for implemented fixes (I events) of the mode BC10. In the graph the I events are symbolized by having the letter "I" before the naming of the mode, in this case IBC10 for the implemented fix of mode BC10. The IBC10 in the equivalent single system is calculated as  <math>(200+175+200)=575</math> .
 
:4) Figure ESSC20 illustrates the application of rule #4 for the mode BC20 in system 1, which occurs after a fix for the same mode was implemented in system 2. The mode in the equivalent single system is calculated as  <math>(350+300+350)=1000.</math>
<math></math>
<br>
<br>
[[Image:rga9.19.png|thumb|center|400px|Calculating an implementation event.]]
<br>
<br>
[[Image:rga9.20.png|thumb|center|400px|Calculating a BC mode that occurred after I events.]]
<br>
<br>
[[Image:rga9.21.png|thumb|center|400px|Calculating a second occurrence of a BC mode in the same system, after I events have been implemented.]]
<br>
<br>
[[Image:rga9.22.png|thumb|center|400px|Growth Potential MTBF plot from three systems with event codes.]]
<br>
:5) Figure ESSC10econd illustrates the application of rule #5 for the second occurrence of the mode BC10 in system 1, which occurs after an implemented fix (I event) had occurred for that mode in the same system. The mode in the equivalent single system is calculated as  <math>575+(175+200+175)=1125.</math>
 
 
After having transferred the data set to the Crow Extended equivalent single system, the data set is analyzed using the Crow Extended model as presented in this chapter. Figure multipleventP shows the growth potential MTBF plot that is generated from the Multiple Systems with Event Codes data sheet presented in Figure Simple example Crow Extended ESS.
 
 
====Transferring to Crow Extended - Continuous Evaluation Equivalent Single System====
RGA provides the capability to transfer a Multiple Systems with Event Codes data sheet to various other data types. Figure MultipleventoSS 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.
 
<br>
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. This model is covered in detail in Chapter 10 and familiarity with that model is necessary for the discussion presented in this section.
<br>
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):
<br>
<br>
:• 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.
<br>
Figure ESSECE shows the transferred equivalent single system Crow Extended - Continuous Evaluation data sheet from the Multiple Systems with Event Codes data sheet of Figure Simple example Crow Extended ESS.
 
[[Image:rga9.23.png|thumb|center|400px|Transfering the Multiple Systems with Event Codes data sheet to an equivalent single system using the Crow Extended-Continuous Evaluation model.]]
<br>
<br>
[[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.]]
 
<br>
====Iterations====
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.
<br>
<br>
'''Example 7'''
<br>
Consider the example shown in Figure iterationsithout, that 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.
Figure iterationsarning shows a warning when trying to convert this data sheet without using iterations.
 
<math></math>
[[Image:rga9.25.png|thumb|center|400px|Repeated modes without iterations.]]
<br>
<br>
[[Image:rga9.26.png|thumb|center|400px|Warning when converting to Crow Extended- Continuous Evaluation model.]]
<br>
<br>
[[Image:rga9.27.png|thumb|center|400px|Repeated modes with iterations.]]
<br>
<br>
 
'''Solution'''
<br>
Figure iterationsith 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.28.png|thumb|center|400px|Correct transfer to the Crow Extended - Continuous Evaluation model with the use of iterations on modes.]]
<br>
<br>
 
This way, the conversion to the Crow Extended - Continuous Evaluation model occurs in a valid fashion, since 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 Figure iterationsHASES. 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.
 
==General Examples==
===Example 8===
Three systems were subjected to a reliability growth test to evaluate the prototype of a new product. Once the test was completed a failure analysis was done and, based on this, a management strategy was able to be defined. It was determined that all corrective actions will be delayed until after the test. The collected data set is shown in Table 9.6 and the associated effectiveness factors for each unique BD mode are presented in Table 9.7. The prototype is required to meet a projected MTBF goal of 55 hours. Do the following:
<br>
<br>
:1) Estimate the parameters of the Crow Extended model.
:2) Based on the current management strategy what is the projected MTBF?
:3) If the projected MTBF goal is not met, alter the current management strategy to meet this requirement with as little adjustment as possible and without changing the EFs of the existing BD modes. Assume an EF = 0.7 for any newly assigned BD modes.
 
 
{|style= align="center" border="1"
|-
|colspan="4" style="text-align:center"|Table 9.6 - Multiple Systems (Concurrent Operating Times) data for Example 8
|-
!
!System 1
!System 2
!System 3
|-
|Start Time||0|| 0|| 0
|-
|End Time||541|| 454|| 436
|-
|Times-to-Failure|| 83 BD37|| 26 BD25|| 23 BD30
|-
| ||83 BD43|| 26 BD43|| 46 BD49
|-
| ||83 BD46|| 57 BD37|| 127 BD47
|-
| ||169 A45|| 64 BD19|| 166 A2
|-
| ||213 A18|| 169 A45|| 169 BD23
|-
| ||299 A42|| 213 A32|| 213 BD7
|-
| ||375 A1|| 231 BD8|| 213 BD29
|-
| ||431 BD16|| 231 BD25|| 255 BD26
|-
| || ||231 BD27|| 369 A33
|-
| || ||231 A28|| 374 BD29
|-
| || ||304 BD24|| 380 BD22
|-
| || ||383 BD40|| 415 BD7
|}
 
<br>
 
{|style= align="center" border="1"
|-
|colspan="2" style="text-align:center"|Table 9.7 - Effectiveness factors for Example 8
|-
!BD Mode
!Effectiveness Factor
|-
|30|| 0.75
|-
|43|| 0.5
|-
|25|| 0.5
|-
|49|| 0.75
|-
|37|| 0.9
|-
|19|| 0.75
|-
|46|| 0.75
|-
|47|| 0.25
|-
|23|| 0.5
|-
|7|| 0.25
|-
|29|| 0.25
|-
|8|| 0.5
|-
|27|| 0.5
|-
|26|| 0.75
|-
|24|| 0.5
|-
|22|| 0.5
|-
|40|| 0.75
|-
|16|| 0.75
|}
 
 
[[Image:rga9.29.png|thumb|center|300px|Entered data and the estimated Crow Extended parameters.]]
<br>
<br>
[[Image:rga9.30.png|thumb|center|300px|Calculate the projected MTBF.]]
<br>
 
[[Image:rga9.31.png|thumb|center|300px|Individual Mode Failure Intensity chart.]]
 
<br>
[[Image:rga9.32.png|thumb|center|300px|Calculate the projected MTBF based on the change to the management strategy.]]
 
<br>
<br>
====Solution to Example 8====
:1) Figure CrowExtend2 shows the estimated Crow Extended parameters.
:2) There are a couple of ways to calculate the projected MTBF, but the easiest is via the Quick Calculation Pad (QCP), as shown in Figure CrowExtend3.
:3) From the previous question, the projected MTBF is estimated to be 53.9390 hours, which is below the goal of 55 hours. To reach our goal, or to see if we can even get there, the management strategy must be changed. The effectiveness factors for the existing BD modes cannot be changed, however it is possible to change an A mode to a BD mode. But which A mode(s) should be changed? To answer this question, you can view the Individual Mode Failure Intensity plot with just the A modes displayed as shown in Figure CrowExtend4. As you can see from the plot, failure mode A45 has the highest failure intensity. Therefore, among the A modes this particular failure mode is having the greatest negative effect in regards to the system MTBF. So change A45 to BD45. Be sure to change all instances of A45 to a BD mode. Enter an effectiveness factor for BD45 equal to 0.7 and recalculate the parameters of the Crow Extended model. Now go back to the QCP to calculate the projected MTBF as shown in Figure CrowExtend5. The projected MTBF is now estimated to be 55.5903 hours. Based on the change in the management strategy, the projected MTBF goal is now expected to be met.
<br>
<br>
 
===Example 9===
<br>
A reliability growth test was conducted for 200 hours. Some of the corrective actions were applied during the test while others were delayed until after the test was completed. The data set is given in Table 9.8. The effectiveness factors for the BD modes are given in Table 9.9. Do the following:
<br>
<br>
:1) Estimate the parameters of the Crow Extended model.
:2) Determine the average effectiveness factor of the BC modes using the Function Wizard.
:3) What percent of the failure intensity will be left in the system due to the BD modes after implementing the delayed fixes?
<br>
 
{|style= align="center" border="1"
|-
|colspan="4" style="text-align:center"|Table 9.8 - Grouped Failure Times data for Example 9
|-
!Number at Event
!Time to Event
!Classification
!Mode
|-
|3|| 25|| BC|| 1
|-
|1|| 25|| BD|| 9
|-
|1|| 25|| BC|| 2
|-
|1|| 50|| BD|| 10
|-
|1|| 50|| BD|| 11
|-
|1|| 75|| BD|| 12
|-
|1|| 75|| BC|| 3
|-
|2|| 75|| BD|| 13
|-
|1|| 75|| A||
|-
|1|| 100|| BC|| 4
|-
|1|| 100|| BD|| 14
|-
|1|| 125|| BD|| 15
|-
|1|| 125|| A||
|-
|1|| 125|| A||
|-
|1|| 125|| BC|| 5
|-
|1|| 125|| BD|| 10
|-
|1|| 125|| BC|| 6
|-
|1|| 150|| A||
|-
|1|| 150|| BD|| 16
|-
|1|| 175|| BC|| 4
|-
|1|| 175|| BC|| 8
|-
|1|| 175|| A||
|-
|1|| 175|| BC|| 7
|-
|1|| 200|| BD|| 16
|-
|1|| 200|| BC|| 3
|-
|1|| 200|| BD|| 17
|}
 
 
{|style= align="center" border="1"
|-
|colspan="2" style="text-align:center"|Table 9.9 - Effectiveness factors for Example 9
|-
!BD Mode
!Effectiveness Factor
|-
|9|| 0.75
|-
|10|| 0.5
|-
|11|| 0.9
|-
|12|| 0.6
|-
|13|| 0.8
|-
|14|| 0.8
|-
|15|| 0.25
|-
|16|| 0.75
|-
|17|| 0.8
|}
 
====Solution to Example 9====
:1) Figure CrowExtend6 shows the estimated parameters of the Crow Extended model.
:2) After inserting a General Spreadsheet into the Folio, the Function Wizard can be accessed via the Tools menu. Once the Function Wizard is loaded, select Average Effectiveness Factor from the list of available functions and under Avg. Eff. Factor select BC modes as shown in Figure CrowExtend7. Click OK and the result will be placed into the General Spreadsheet. The average effectiveness factor for the BC modes is 0.6983.
:3) The percent of the failure intensity left in the system due to the BD modes can be determined using the Failure Mode Strategy plot as shown in Figure CrowExtend8. Therefore, the percent of the failure intensity left in the system due to the BD modes is 1.79%. 
 
[[Image:rga9.33.png|thumb|center|300px|Entered data and the estimated Crow Extended parameters.]]
 
[[Image:rga9.34.png|thumb|center|300px|Calculate the average effectiveness factor for the BC modes using the Function Wizard.]]
 
[[Image:rga9.35.png|thumb|center|300px|Failure Mode Strategy plot.]]
<br>
 
===Example 10===
<br>
Two prototypes of a new design are tested simultaneously. Whenever a failure was observed for one unit, the current operating time of the other unit was also recorded. The test was terminated after 300 hours. All of the design changes for the prototypes were delayed until after completing the test and the data set is given in Table 9.10. Assume a fixed effectiveness factor equal to 0.7. The MTBF goal for the new design is 30 hours. Do the following:
<br>
<br>
:1) Estimate the parameters of the Crow Extended model.
:2) What is the projected MTBF and growth potential?
:3) Under the current management strategy, is it even possible to reach the MTBF goal of 30 hours?
<br>
 
 
{|style= align="center" border="1"
|-
|colspan="5" style="text-align:center"|Table 9.10 - Multiple Systems (Known Operating Times) data for Example 10
|-
!Failed Unit ID
!Time Unit 1
!Time Unit 2
!Classification
!Mode
|-
|1|| 16.5|| 0|| BD|| seal leak
|-
|1|| 16.5|| 0|| BD|| valve
|-
|1|| 17|| 0|| A||
|-
|2|| 20.5|| 0.9|| A||
|-
|2|| 25.3|| 3.8|| BD|| hose
|-
|2|| 28.7|| 4.6|| BD|| operator error
|-
|1|| 41.8|| 14.7|| BD|| bearing
|-
|1|| 45.5|| 17.6|| A||
|-
|2|| 48.6|| 22|| A||
|-
|2|| 49.6|| 23.4|| BD|| seal leak
|-
|1|| 51.4|| 26.3|| A||
|-
|1|| 58.2|| 35.7|| BD|| seal leak
|-
|2|| 59|| 36.5|| A||
|-
|2|| 60.6|| 37.6|| BD|| hose
|-
|1|| 61.9|| 39.1|| BD|| seal leak
|-
|1|| 76.6|| 55.4|| BD|| bearing
|-
|2|| 81.1|| 61.1|| A||
|-
|1|| 84.1|| 63.6|| A||
|-
|1|| 84.7|| 64.3|| A||
|-
|1|| 94.6|| 72.6|| A||
|-
|2|| 100|| 78.1|| BD|| valve
|-
|1|| 104|| 81.4|| BD|| bearing
|-
|2|| 104.8|| 85.9|| BD|| spring
|-
|2|| 105.9|| 87.1|| BD|| operator error
|-
|1|| 108.8|| 89.9|| BD|| hose
|-
|2|| 132.4|| 119.5|| BD|| spring
|-
|2|| 132.4|| 150.1|| BD|| operator error
|-
|2|| 132.4|| 153.7|| A||
|}
 
<br>
====Solution to Example 10====
<br>
:1) Figure CrowExtend9 shows the estimated Crow Extended parameters.
:2) One possible method to calculate the projected MTBF and growth potential is to use the Quick Calculation Pad, but you can also view these two values at the same time by viewing the Growth Potential MTBF plot, which is displayed in Figure CrowExtend10. From the plot, the projected MTBF is equal to 16.87 hours and the growth potential is equal to 18.63 hours.
:3) The current projected MTBF and growth potential MTBF are both well below the required goal of 30 hours. To check if this goal can even be reached, you can set the effectiveness factor equal to 1. In other words, if all of the corrective actions were to remove the failure modes completely then what would be the projected and growth potential MTBF? After changing the fixed effectiveness factor to 1, the parameters are recalculated and the Growth Potential plot is refreshed. The refreshed plot is shown in Figure CrowExtend11. Even if you assume an effectiveness factor equal to 1, the growth potential is still only 27.27 hours. Based on the current design process, it will not be possible to reach the MTBF goal of 30 hours. Therefore, there are basically two options: start a new design stage or reduce the required MTBF goal.
 
<math></math>
[[Image:rga9.36.png|thumb|center|300px|Entered data and the estimated Crow Extended parameters.]]
<br>
<math></math>
[[Image:rga9.37.png|thumb|center|300px|Growth Potential MTBF plot (EF=0.7)]]
<br>
<br>
[[Image:rga9.38.png|thumb|center|300px|Growth Potential MTBF plot (EF=1)]]
 
<br>

Latest revision as of 01:11, 23 August 2012

Redirect to:

Retrieved from "https://www.reliawiki.com/index.php?title=Template:Rga_crow_extended&oldid=33264"