Ok, thanks for the many tips and advice.

To go back to my question, what would be your calculated mtbf for the Rui's example above?

Josh,

When dealing with historic numbers, the more data you consider (farther back in time) in order to compute an average for instance, the poorer the response will be to more recent inputs, but, in turn, the more stable the indicator will be. The only way out consists in performing a trade-off. Please see the example in Excel that I attach. It deals with data that, despite erratic from one period to the other, presents a trend though. This trend can be due to some improvements that are being implemented consistently over time, such as the ones to be expected from a TPM program.

The shorter the period (not a constant time window in this case but rather a fixed number of events), the better the response, that is, the better the picture of the magnitude the TTF´s are reaching actually.

On the other hand, if a piece of equipment suffers a radical change in what its reliability is concerned, then past data will be of little use from that moment on. New data will have to be collected in order to have refreshed indicators available reflecting the new reality.

Regards

This message has been edited. Last edited by: <Rui Assis>,

MTTF_control.xls (19 Kb, 79 downloads)

Josh,

Please find attached a new version of the same Excel file I attached to my latest post. This time I included an example of weighted values. Notice that the indicator shows a higher value than the one in the case of simple averages (492 against 479 specifically) which confirms a better response.

Regards

This message has been edited. Last edited by: <Rui Assis>,

MTTF_control_1.xls (28 Kb, 60 downloads)

Rui

I have redone your example as attached. A few questions:

Is the MTTF always a straight line ie Y=mX +C? Is this the most representative of MTTF?

Why can't we just estimate the MTTF by averaging TTFs at each failure event as per the third chart on right most?

My intention is to track the MTTF or MTBF value monthly, whether there is a failure or not. Which is the best approach to calculate the MTTF or MTBF value?

This message has been edited. Last edited by: Josh,

6611007803_MTTF_control_1(1).xls (55 Kb, 53 downloads)

Rui

I have re-calculate the MTBF, MTTF & MTTR using the total operating time from the beginning to today i.e. without using the constant time window. Is it correct?

From your second example attached above, what I understand is that using constant time windown to calculate MTBF will give higher values if there are improvements made during that constant time window.

My problem with using the constant time window to calculate MTBF etc is that none of published MTBF data like HP Bloch books mention about using constant time window or did I miss something?

My second concern with using the constant time window to calculate MTBF etc is that, what is the most appropriate constant time windows to be used so that I can compare my MTBF data with others' data? In view of this, look like calculating the MTBF every month seems ok for trending purposes and comparing with the same industrial data published by others.

Copy_of_1581080803_Indicators.xls (44 Kb, 53 downloads)

Josh,

An indicator is meant very often to anticipate the behavior of a system within a few periods ahead. To do this, the indicator has to be built on data collected for a while in the recent past – typically a time window whose length has to be adjusted now and then in order to compromise stability (the property of not going up and down suddenly) and responsiveness (the property of following the latest trend closely). Things that have long happened are only interesting for historical records. This way, the decision maker gets the best possible picture regarding the direction an indicator is taking and can act accordingly. Note that a sudden move up (or down) in the last control period doesn’t mean necessarily that you are moving towards disaster nor heaven. Management should be more concerned and focused on trends rather than specific values from one period to the other. But the trend cannot be built on a long period; otherwise management won’t get response but too much stability instead and it will be too late when he finally notices an undesirable trend.

The weighed data methods that I wrote about in my previous posts on this thread offer a way of getting the best possible trend awareness.

This is why you should use a time frame and not a period as long as possible to calculate an indicator, unless it corresponds to the very minimum time span to accommodate a few events to be statistically significant. I saw your calculations and I would agree with them if I were not aware of the fact that you are simply trying to get rid of the time window constraint!

I hope you agree this time.

I am sorry I cannot give you a straight answer in what norms are concerned. I always follow the practices that I think are the best to a specific case whenever I implement a management performance control system and never accept an indicator calculated in a way imposed by some norm whose logic or justification I don’t agree with. This is to say that I don’t follow norms in what “management performance control systems” are concerned but I, of course, accept to consider any when a client points me out in that direction with the condition that I freely decide whether to advise (and justify) its adoption or not.

Regards.

This message has been edited. Last edited by: <Rui Assis>,

Normally use MTBF for equipment, Can I calculate for a single failure mode?

Example : MTBF of Bearing pump, Fan belt etc.

Of course, you can do at failure mode level the same as you do at equipment level. But this is more the concern of engineering engaged in measuring and improving reliability of a particular item. Management doesn’t pay attention at such a high degree of detail.

Regards,

If you code every possible failure mode at components level, then you can be effective at judging equipment level performance on a timely basis, by just consolidating figures gathered at that low level. This way, you get figures useful for both reliability improvements and management performance follow-up.

By the way, I sometimes have doubts on how to translate a specific failure mode into a code suitable to be dealt by computers. Does anyone in this forum have a good experience in failure mode coding? A few examples would be highly appreciated.

Regards,

Rui,

Ok, your explanation is clearer this time above. I think you said that my approach of calculating the MTBF based on the longest time window gives stability but not responsiveness. How to strike a balance?

"typically a time window whose length has to be adjusted now and then in order to compromise stability (the property of not going up and down suddenly) and responsiveness (the property of following the latest trend closely)."

In the sentence above, don't you mean ".. in order NOT to compromise BOTH stability and responsiveness"?

To get the optimum stability and responsiveness, how do I select the constant time window to calculate the MTBF? Normally, we report KPIs monthly but look like from your example, the constant 3 monthly time window shows good improvement of the MTTF.

Further, how do I select the appropriate weightage to be applied to the recent data?

Do you know which English references discuss this matter at length?

Rui

In SAP Plant Maintenance, there are 3 fields to be entered for each item (failure) record in the Notification screen, namely Object part, Damage code and Cause code. You can refer to ISO14224 for examples how an equipment is broken down into parts etc.

Cheddar, after you calculate your first MTBF for the first 6 months, how often do you then recalculate it for KPI reporting purposes?

This message has been edited. Last edited by: Josh,

Rui

What is the meaning of "moving constant time window"? Is it:

a) (Jan, Feb & Mar), (Apr, May & Jun), (July, Aug & Sep), (Oct, Nov & Dec) or

b) (Jan, Feb & Mar), (Feb, Mar & Apr), (Mar, Apr & May), (Apr, May, Jun), (May, Jun & Jul), (Jun, Jul & Aug), (Jul, Aug & Sep), (Aug, Sep & Oct), (Sep, Oct & Nov), (Oct, Nov & Dec), (Nov, Dec & Jan), (Dec, Jan & Feb)?

Josh,

I think the example I attach is self-explanatory. Here you have 26 TTF collected over time (it doesn’t matter for how long). In one page you have simple averages and weighted averages in the other. The 27th event is still to happen. The indicator MTTF can already be calculated though, and its value can be interpreted as an estimate of the MTTF at the time of the 27th event (cells D34 and E34). But if you are confined to reporting past events, then, cells D33 and E33 are the only ones to be considered.

The techniques that I use in management performance control are basically the same typically used in forecasting.

In this e-book: http://home.ubalt.edu/ntsbarsh/stat-data/Forecast.htm#rhowma, you can find a brief description of these techniques.

Regards,

This message has been edited. Last edited by: <Rui Assis>,

MTTF_trend_example.xls (38 Kb, 59 downloads)

Josh,

MAD (mean absolute deviation) provides a measure of how close you are of reality when performing forecasts. Its value is desirable to be as close to zero as possible. MAD is a popular indicator to choose among different methods.

Regards,

This message has been edited. Last edited by: <Rui Assis>,

Caro Rui, è com enorme prazer que lhe escrevo, pois adquiri recentemente um livro seu (Apoio á Decisão em Gestão da Manutenção). Eu estive a ler as mensagens neste tópico, e confesso que estou um pouco confuso. Eu tenho uma linha de produção em que tenho 10 tipos de equipamentos diferentes (tenho registado todas as paragens de cada, o tempo de espera do técnico e também o tempo de reparação). o que gostava de saber (porque eu vejo tantas formulas, é qual formula eu tenho de usar para calcular o meu MTBF, MMTR, Fiabilidade e Disponibilidade. Junto envio um ficheiro em Excel (penso que foi o Rui que enviou para este fórum) mas penso que só se aplica a um grupo de equipamentos iguais.
Com isto eu quero calcular a Fiabilidade de cada equipamento bem como do sistema completo (que é um sistema série+paralelo).
Desde já agradeço a atenção disponibilizada.

Cumprimentos,

Joaquim Silva

it@gewiss.pt

In many situations a unit or system can be repaired immediately after breakown. In such cases the mean time between failurerefer to the average time of breakdown until the device is beyond repairs.
For an exponential failure rate , mean time between failures is 1/failure rat and this indicates the average interval of time between failure of the equipment.
The mean time between failure is not the time for which the equipment will be expected to operat before failure . For example , if equipment is to operate for a period equal to MTBF , then the probability of the equipment lasting for that period of time without failure is about 40%. Obviouslyif the equipment is used for a shorter period of time the probability of survival is higher.
The MTBF is therefore the average time between failure and in practical terms it can be obtained by calculating :
Total Operating time of Population
MTBF= ----------------------------------
No of failures to occure

For eample , suppose there are 100 identical pieces of equipment in operation in various systems each of which has been in operation for about 8000 Hrs- this means that the total operating for the poulation is 800000 Hrs. and also suppose that during this period of time 80 failures have occured and have been repaired so that each runs 8000 hrs: the MTBF is therefore 80000/80 = 10000 Hrs. The failure rate is the reciprocal of this and is 0.0001.

Attached a very simple example yet usefull example of a rolling MTBF calculation for a unit. This is usefull when start and end dates and time of failure are not reliable.
Note that it must be done on equal equipment in de same operating conditions.

Rolling_MTBF_calculation_example.xls (63 Kb, 71 downloads)

Hello,

I have the system that you see in the attachment, i would like to calculate the:

By equipment:

- MTBF
- MTTR
- MWT
- MTTF
- Availability
- Reliability

By system:

- MTBF
- MTTR
- MWT
- MTTF
- Availability
- Reliability

It’s possible?

Silva

production_line.xls (23 Kb, 62 downloads)

dear partners,

It´s possible or not to make this calculations?

Thanks

Silva