Using RG for multisystem multistage developmental testing

[Al]

Hi,

We have about 3 developmental stages; in each one we have about 3 to 4 systems. Failure can be corrected immediately, postponed or ignored. After the end of a developmental stage more modification are performed on the design and new units are built and put into the test of the next developmental stage (which means we are starting with new systems again). How could that be expressed in RG?

I am using the 'Developmental Testing-Multiple Systems-Unknown Equivalent Times' data type. Right now I have separate files for each developmental stage (with its multiple systems). The analysis I have only tracks the growth during each developmental stage.

How could I get an idea about the growth throughout my entire reliability growth program, meaning from the beginning of stage 1 till the end of stage 3?

How could I find out how my improvements between stages (when no test is being done) affected the reliability?

Thanks for your help.

[adam]

The way that you are treating the data is correct. The Crow-AMSAA and Crow-Extended models apply to data within phases. In order to track the reliability growth across phases you would have to use another model and data. You can convert your demonstrated MTBF at the end of each phase to a reliability value and use the reliability data type in RG. You would have to use the exponential assumption in order to get the reliability (exp(-lambda*t)).

For your second question regarding the improvements between stages, you can calculate the initial MTBF at the beginning of each stage. In theory the initial MTBF is:

MTBFi = gamma_fnc(1+1/beta) / lambda^(1/beta)

You can get this value in RG by inserting a general spreadsheet, using the Function Wizard, and selecting MTBF(Initial) from the list.

Once you obtain the initial MTBF, you can then compare it to the demonstrated MTBF value of the previous stage, in order to get the impact of the improvements between stages.

I am assuming that you are using the Crow-Extended model in order to predict the MTBF jump due to delayed fixes. If yes, then you can use the above method in order to compare your predicted projected MTBF to the initial MTBF of the next stage. This will give you a better understanding of the "true" average effectiveness factor and the assumed one. You can then utilize this information in future projects in order to assign more realistic effectiveness factors when you do projections.

[Al]

Thanks for your reply.

1- When would you select the 'Dates are considered' option under 'Set Analysis'? and for what purpose?

2- As a way to get un understanding about my reliability growth throughout the whole stages, I thought about putting all my data into one file and selecting the 'Dates are considered' option. What does this analysis tell me?

3- In case of delayed fixes with multiple systems, there is no value for lambda, yet there is a value for MTBFi, which is a little confusing considering that the MTBFi depends on both beta and lambda, as the equation you provided shows! When there is no fixes, the value for MTBFi is ‘Not Available’!! Yet according to the equation you mentioned, this can be calculated since I have lambda and beta?

Thank you

[adam]

1- Dates are used when testing multiple systems, where the systems are not run simultaneously. When testing multiple systems you need to know the run-hours of each system in the test when a failure occurs. Since in practice you may not know this information, we use the dates and the failure data of each system to estimate its run hours. This is done by calculating an average usage rate. For example, say you are testing two systems. One is tested in the US, the other in Europe. Furthermore, if there are fixes available, they are implemented in both systems at reasonably the same time. The test starts on Jan 1st. System 1 fails on Jan 5th after 25hrs of operation. System 2 fails on Jan 10 after 30 hrs of operation. This means that an average usage per day for system 2 is 3hrs. From this we can say that when system 1 failed, system 2 had 15hrs of operation. This information is needed because we need to calculate the cumulative test time at each failure. So in this example when system 1 failed the cumulative test time was 25+15=40hrs.

2- I hope the above explanation answers this question.

3- When you only have delayed fixes, beta is assumed to be 1. This means that your initial MTBF is equal to the final MTBF which is equal to the instantaneous MTBF and the cumulative MTBF which is simply Total Test Time / Number of Failures. In other words since you are not doing anything during the test to influence the MTBF, then it wouldn't change from its initial value.