MTBF estimation

[radhi]

1. for a series system with two systems(A & B) (with the following configuration), i need to know the overall system MTBF).
- Overall system MTBF(A&B systems) = 10000 hours
- System A consists of a parallel configuration of systems A1 & A2 with MTBF of each (A1/A2) as 6000 hrs.Therefore, System 'B' MTBF=9000 hours
- MTBF of B system to be estimated???-

if i connect in series configuration, Overall MTBF(10000) = 1/(failure rate of A +failure rate of B)

since, the system 'A' is in parallel configuration,we cannot invert to get the MTBF.

could somebody help me, how to estimate MTBF of the above configuration & MTBF of 'B'system.

[tarik]

It is not cleat to me what the configuration of your system is!

The reliability for n components in series is
Rs= R1 x R2 x .. x Rn
http://www.weibull.com/SystemRelWeb/series_system.htm

The reliability for n components in series is
Rs= 1-(1-R1) x (1- R2) x .. x (1- Rn)
http://www.weibull.com/SystemRelWeb/simple_parallel_systems.htm

- If you are assuming an exponential distribution for your components:
Then the MTBF for a system’s in-series configuration is

MTBFs = 1/(failure rate of component 1 + failure rate of component 2 + ….+ failure rate of component n)

For the case of parallel, it becomes more complex
MTBF = Integration (0 to infinity) of Rs(t)

BlockSim provides easy and quick tools to obtain those answers
http://www.weibull.com/systemrelwebcontents.htm
http://www.reliasoft.com/BlockSim/index.html

[Rui Assis]

I would like to have Tarik´s comments on the following:

I think that the expressions in the previous post apply solely to systems (repairable or non-repairable) whose failures are caused by chance. If you have a repairable system whose components degrade according to, for instance, Weibull functions, the reliability R, once the steady state is achieved, is given by R = exp(-lambda x mission). This expression applies so much the better as the number of components increases regardless the shape of the specific failure function of each component. In this expression, lambda is the system failure rate and is computed by the sum of lambdas pertaining to each component. The lambda of each component is in turn calculated by: lambda = 1 / [location parameter + scale parameter x gammafunction(1 + 1/shape parameter)].

Example
A systems has three components (A, B and C). Dominant failures are described by Weibull functions with the below described parameters. Mission is 2500 hours.

Location parameter
A – 1500; B – 2200; C – 1800
Scale parameter
A – 6000; B – 7000; C – 6000
Shape parameter
A – 1.8; B – 2.2; C – 3.9

Lambda A = 1 / [1500 + 6000 x gammafunction(1 + 1/1.8)] = 0.00015
Lambda B = 1 / [2200 + 7000 x gammafunction(1 + 1/2.2)] = 0.00012
Lambda C = 1 / [1800 + 6000 x gammafunction(1 + 1/3.9] = 0.00014

The system lambda equals 0.00015 + 0.00012 + 0.00014 = 0.00041 and MTTF = 1/0.00041 = 2439 hours

Then R = exp(-0,00041 x 2500) = 0.3645 which is completely different from R = Ra.Rb.Rc = 0.96103 x 0.99902 x 0.99977 = 0.95987

This same result can also be achieved by Monte Carlo simulation.

Am I wrong?

[radhi]

thanks for the inputs tarik & Rui.

to clearly specify from problem, i consider sytem a& sytem B have a constant failure rate (lambda).
if connected in series configuration, we have the following data:
- constant failure rate considered for each component.
System A has two components in parallel (with each component MTBF = 6000 hrs). therefore System A MTBF =9000 hours(computed from 3/2lamda)
system B - MTBF unknown.
Overall sytem MTBF = 10000 hrs minimum specified.

a) considering total as repairable system with
constant failure rate, how to compute MTBF of B system.

i agree with Mr Rui Asis comments if it is for weibull failure and considering a single component, but here system A is in parallel configuration. so i cannot use MTBF=1/Lambda.

is there any method to compute MTBF of A and also to meet system MTBF of minimum 10000hrs.

[Rui Assis]

Radhi,

If I well understood your problem, I think there is an impossibility in your data, as the MTTF of a series system (A + B) cannot ever be higher than any of its components. If MTTF of the subsystem A is 9000, the MTTF of the entire system has to be less than 9000, no matter what the MTTF of subsystem B might be.

[tarik]

Please note this correction for my previous post:
The reliability for n components in PARALLEL is
Rs= 1-(1-R1) x (1- R2) x .. x (1- Rn)

[tarik]

I think you are making as assumption that many people make, which to approximate a system made of various compoents, each one following any kind of distribution) to the exponential distribution. This assumption is not correct.

Now let me cover some useful formulas:

For the case of (2-parameter) Weibull distribution:
-Lambda(t) = beta/eta x (t/eta)^(beta-1). The failure rate (lambda) depends on time (except if beta=1)
-MTTF =eta x GammaFunction(1/beta + 1)

Using the equations, I covered in my first and second post you can calculate the system reliability and obtain the failure rate (depending on time). Even if you have a constant failure rate (exp distribution) across all your components, the system failure rate still depends on time (except if all the components are in series)

[tarik]

The comment in Rui 2nd post is generally correct.

If Subsystem A is made of 2 components in parallel each one follows an exp(6000), then component A’ MTTF is 8996.7479.

If Subsystem A is in series with another subsystem (B), then the system’s MTTF can’t be greater then 8996.7479 no matter how reliable B is.

[Rui Assis]

Tarik,

The first formula you gave in your last post refers to the instantaneous hazard function, which of course depends on time, and the second refers to mean life. If you have a mean life, say MTTF, you can compute an average frequency of failures (due to wear as you don’t do preventive maintenance) by doing 1/MTTF. Being so, I am quite confident in the result of the example that I posted above, where an exponential function applies to the system as a whole, independently of the individual probability functions. The exponential function applies so much the better as the number of components increases regardless the shape of the specific failure function of each component.

You can have an evidence of this fact if you build a simulation model like I did. Rs = Ra x Rb x Rc x Rn doesn´t apply at all. I cannot see the reason why this assumption is not correct. I´ll appreciate once more to have your comments on this.

[Rui Assis]

Tarik,

A note to my previous post:

The simulation model I refered yelds Rs aproximately equal to 0.3645 - which agrees with the analytical result - if you consider the system as being repairable. If you consider the system not being repairable, then you get aproximately 0,95987 which agrees with Ra x Rb x Rc. Thanks.

[tarik]

I have the following comments:
- I performed a simulation with 10,000 simulation with BlockSim, the result I obtained, for your example, is Rs(2500)=0.9624 not 0.3645 as you said.
- I noticed that you used location parameters in your Weibull distributions. When you specify a positive location parameter for a component, that means that your component can never fail for that duration.
Read the following material for more details:
http://www.weibull.com/hotwire/issue15/relbasics15.htm
The shape (beta) parameter is a very crucial parameter, it can’t be ignored in most important calculations and metrics, as you can see in the following reference:
http://www.weibull.com/LifeDataWeb/characteristics_of_the_weibull_distribution.htm

- If you specify very high location parameter values (as you did in your example) in addition to large scale parameters(eta), then when you compute the reliability for a mission time that is less then the location parameter, then that component didn’t reach the critical period when you start seeing a significant increase in failure rate (wareout), that is why you notice that the shape parameter has less influence (especially for larger values of beta, which mean less variability). What you described is not general, it ‘s a very special situation.

[Rui Assis]

Tarik,

Thank you for your comments.

I didn´t ignore shape parameters in my calculations neither in my simulation model, I didn´t compute a mission time that is less than any of the location parameters, I am well aware of the importance of the relativeness among the several parameters and still our results don´t match. I tried many other values (with and without location parameters) and my results are consistent. I am sorry if I insist with my view points, but I am well acquainted with reliability and maintainability and I feel discomforted with your comments. If I am wrong, I want to be convinced by Reliasoft arguments and correct my self for the future. For the time being, I am absolutely convinced that I am right.

Please note that I am considering a repairable system composed by three components. In the simulation model, TTF´s are generated randomly according to three Weibull distributions. In each iteration, a component fails (the one presenting the shortest TTF). Then, the system stops and the failed component is replaced by a new one and the other two remain in place. These two keep memory of their degradation level at the time the system was stopped. This circumstance (one brand new and two “old”) will be taken into account when a new group of TTF´s is generated. The system MTTF must result 2477 and reliability 0.3645.

I tried BlockSim Version 6.2 and the result is Rs = 0.9599 (for a mission of 2500). I activated the Maintenance option in Block Properties, selected Can Maintain Correctively and chose Fixed Duration A: 4; B: 28; C: 6. Back to the QCP, the reliability surprisingly remained the same, that is 0,9599. How can it be? No change if the system becomes repairable? More surprisingly yet, was the figure I got for the system MTTF (5259). It can´t be by no means, it should yeld MTTFs = 2477. Have I done anything wrong using BlockSim? (it was the first time I used it).

Thank you again.

[Rui Assis]

Tarik,

One more note:

I came back to my simulation model (developed in VBA by myself) and confirmed my suspicion. You are considering a non-repairable system; In fact, the results Rs = 0,9599 and MTTF = 5259 given by you and obtained from BlockSim are consistent with this fact. They are the same that I get in my simulation model.
Because I wasn´t succeeded in building a repairable system using blocks in BlockSim, I would very much appreciate to have your instructions on how to.

Thanks once more.

[tarik]

This discussion started with Radhi’s question, which didn’t have an indication of repairable system analysis, this why I was not discussion what happens in the case of repairable systems. I am sorry that I didn’t notice you were talking about repairable systems.

In BlockSim, you need to use simulation if you have a repairable simulation, the term ‘reliability’ is generally not used when you have repairable systems, instead the availability of the system (which depends on the reliability of the components and maintainability issues). When you use the analytical QCP, the results are based on the RBD ignoring the repairable information. So, you need to use the Simulation QCP in order to obtain availability and repairable cost analysis.

Your repairable system MTTF shouldn’t change much from the non-repairable system MTTF unless you have preventive maintenance, because if you only have corrective actions, then your components failures will still happen at the same rate, whereas when you have preventive maintenance the components’ failures will be delayed. You should focus more on the availability, uptime, downtime.. metrics in this case.

BlockSim simulation’s QCP shows that the MTTF= 5260.6077 for the repairable system, not 2477 that you proposed. By the way, have you noticed that your proposed repairable system’s MTTF is smaller then the non-repairable system’s MTTF (5259)?! How do you explain that your system will become less 'reliable' when introducing repairs?!

[Rui Assis]

Tarik,

Thank you for your insistance in trying to convince me - which you haven´t so far. Please consider the following comments:

Reliability of a repairable system can be seen as the number of times that TTF (time between two successive failures of any of the components) results shorter than the mission time. It is true that it is not much used but, nevertheless, it can be calculated and it can be seen in the System Overview of BlockSim and it works. Of course other metrics such as availability are far more important - I am well aware of that.

O.K. I will keep in my mind that whenever I want to study a repairable system with BlockSim I shall have to use Simulation QCP.

Please note that in a non-repairable system you replace the whole system whenever a component fails (a missile, a satellite, etc.), whereas in a repairable system you replace solely the failed component. The other components keep memory of their state of deterioration and are going to fail sooner, after the last failure, than if they were all brand new. That is why the MTTF is going to be much less. It is a renewal process that I am talking about. It is a fundamental difference.

In a non-repairable system you use the term MTTFF – Mean Time To First Failure (that´s the term that figures in the System Overview in BlockSim). When it comes to a repairable system that is maintained correctively you use the term MTTF – Mean Time To Failure. If a repairable system is maintained preventively, you use the term MTTM – Mean Time To Maintenance, instead.

I tried BlockSim lots of times with different data of non-repairable systems and compared the results with my own that came out of my simulation model and everything is consistent and the term MTTFF applies. Nonetheless, in case of a repairable system, I don´t accept the results returned by BlockSim. By the way, why BlockSim doesn´t distinguish between MTTFF and MTTM?

Thanks.

[tarik]

We have the same definition of repairable systems. Our difference is in how your simulation work
The questions that still intrigues me is why does your system’s MTTF become worse (smaller), ie a failure will happen sooner, when you have corrective actions (i.e. when it becomes a repairable system)? Corrective/preventive maintenance is applied to improve a system not to make it worse!

You asked about MTTM, you can obtain it from BlockSim by dividing your mission time by the number of expected PMs

[Rui Assis]

Tarik,

Your point: The questions that still intrigues me is why does your system’s MTTF become worse (smaller), ie a failure will happen sooner, when you have corrective actions (i.e. when it becomes a repairable system)?

My point: I have already explained why it is so. Moreover, when you buy a new car, the time interval until you suffer a first failure TTFF is surely wider than the TTF&acute;s later as the car approaches the steady state in what failures (or replacement of parts) is concerned. Therefore, MTTF will be < than MTTFF. On the other hand, I do corrective maintenance because I am not reach (crazy?) enough to change to a brand new car whenever a failure occurs, instead to have it fixed.

Your point: Corrective/preventive maintenance is applied to improve a system not to make it worse!

My point: I decide to do preventive maintenance in order to improve the system and this means to get lower average maintenance costs or higher average availability. The increase of MTTM doesn&acute;t lead necessarily to lower costs or higher availability and, therefore, doesn&acute;t have to be seen as an objective. As you know the time interval for preventive maintenance results from a trade off between costs of preventive and corrective tasks or between durations of preventive and corrective tasks - I know that BlockSim deals with this subject.

Thank you for such a stimulating discussion.

[tarik]

I realized a few confusion areas:
- I use the term MTTF and MTTFF interchangeably, I should be more careful with that
- You use MTTF to describe the mean time between subsequent failures, probably the term MTBF (should be probably called MTBF, Mean Time BETWEEN Failures) is more appropriate.

So what is it you were referring to when you said that MTTF should be equal to 2477? MTTFF or MTBF? Originally, my understanding was that you meant MTTFF, that is why I was wondering why does your MTTFnon-repairable (=5259) > MTTFrepairable (=2477, as you said).

If I go under the assumption that you meant MTBF = 2477, then I think that I could agree with that number. I ran 100,000 simulations in BlockSim with an end time=100,000.

The results were as follows:

Expected Number of Failures: 38.8651
MTTFF: 5262.0683
Uptime: 99544.0784

So, MTBF can be calculated as follows:
MTBF= (100,000- 5262.0683)/ 38.8651=2437.609364 (close to your 2477)
Is there in anything you don’t agree with here?


However, note that this average time, includes downtime due to corrective maintenance. Therefore it shouldn’t be interpreted as the uptime duration between failures. I actually don’t like to use the term MTBF to describe what I just calculated, because that might imply that this time doesn’t include downtimes due to corrective action, obtaining parts...etc. And people should be careful in comparing MTBFs of different repairable systems, because you could have a repairable system with MTBF greater then another system’s MTBF and actually have longer uptimes in the second system! I can give you an example if you want.

[Rui Assis]

Tarik,

Thank you for your answer.

The term MTTF comes directly from the integration of the probability density function (PDF), whereas MTBF is equal to MTTF + MTTR. There are authors that give these terms the same meaning that I do and others that don&acute;t, but I can live with it.

I noticed that, in order to calculate the MTBF, you subtracted the MTTFF = 5.262 hours from the time interval 100,000 hours and divided the result by 38.8651 – the average number of failures that took place during the elapsed time. Shouldn&acute;t it be (38.8651 – 1) instead to account for the first failure – whose MTTFF you subtracted in the numerator? I followed the same steps and the results were quite closed to mine. I now feel much more at ease with BS.

With regard to your comments on MTBF, I couldn’t agree more. I have the same problem myself when analysing performance indicators from my clients. In such circumstances, I seek the raw data.

I tried BS once more and didn’t figure out how it decides the time interval for preventive maintenance of each component. I entered the following times for preventive tasks in sheet “Preventive” in Block Properties: 1 hour for block A, 7 for block B and 1.5 for block C. Then, after running the simulator, I visited the Block Summary. Once here, I divided each Block Uptime by the Number of PMs and got 10,700 for block A, 6,954 for block B and 7,499 for block C. How did BS found the number of PM&acute;s? What is the criterion (the rational) behind them? I only know two ways: 1) you set empirically a certain probability of acting correctively, say once in every ten times, or 2) you trade-off costs or durations of corrective and preventive tasks.

Thank you so much in advance.

[tarik]

Your definition of MTBF = MTTF + MTTR along the lines of how I defined it in my previous post. If you had more actions (preventive, inspections…) more terms would be included in the MTBF calculations.

The reason why I subtracted the MTTFF from the total time (100,000) was because I was considering the first failure as my starting point. Probably if you draw a time line with failures then you might see why I calculated the MTBF, the way I did. You don’t have to do it the way I did, you could just do MTBF=100,000/38.8651

As for your question about how does BlockSim find the optimum preventive replacement time, I suggest you read the following material:
http://www.weibull.com/SystemRelWeb/preventive_maintenance.htm

[nc35]

sorry,i don't know,but i surpport you