Calculating MTBF from data

There are occasions when we have either field or test data that includes the duration of operation and whether or not the unit failed. This can be, say, 10 large motors. For sake of argument, the test ran each motor for 1,000 hours and when a motor failed it was repaired quickly and returned to the test. There were 3 failures.

Sadly, this is all we need to calculate an estimate for the motor MTBF.

Total time divided by number of failures in this case is  10 times 1,000 hours for a total time of 10,000 hours. Divide 10,000 by the three failures to find, 3,333 hr MTBF.

What I find interesting is I could find the same MTBF value using 10,000 motors each run for one hour. Or, the same MTBF if we ran one motor for 10,000 hours. IF in each case there were three failures we would find the MTBF of 3,333 hours.

Now that works perfectly well when there is a constant failure rate. Meaning there is equal chance of failure each hour of operation. Old motors would have the same chance of failure as brand new motors.

Of course, you know why I choose motors for the example. To reinforce the idea that the chance of failure is not always a constant. Be sure to think about the failure mechanisms before using MTBF (or MTTF). If the failure rate is time dependent then this simple calculation is not useful.

I used this example during a class last week and it seemed to spark a good discussion. How have you explained MTBF to others? Any suggestions on how to best describe what the MTBF value really means, or doesn’t mean?

About Fred Schenkelberg

I am an experienced reliability engineering and management consultant with my firm FMS Reliability. My passion is working with teams to create cost-effective reliability programs that solve problems, create durable and reliable products, increase customer satisfaction, and reduce warranty costs.

13 thoughts on “Calculating MTBF from data

  1. In my case, trying to calculate reliability and/or MTBF for a subsystem is very frustrating. The advertised reliability of many components are based on the OEM’s projection or engineering analysis because no one wants to spend the dollars and time required to truly test the component thoroughly. Trying to validate their projection or engineering analysis at the system level usually means that my only data is based on one or two failures for a series of tests that accumulate a total of 30 to 40 hours of operation. For simplicity, I am usually forced to ignore the conditions of testing (e.g., temperature, altitude, load). Components that require a high level of reliability (R) and confidence (C) need several hundred hours of operation to fully demonstrate R&C.

    1. Hi Bill, I feel your pain. Vendors have to deal with many operating conditions and use cases. They tend to do what is requested by the majority. Unfortunately, so many seem happy with very poor information, that those that need and request better information and thwarted. I suggest we continue to ask for meaningful information, educate our peers to do likewise, and when all else fails do the testing ourselves.

      Cheers,

      Fred

  2. Hi Fred,
    At the moment I am doing an internship at a company concerning MTBF.
    My research is forcing the same question into my mind everytime: Is it even wise to help them calculate their MTBF? The FR is not constant at all, as they mainly produce flowmeters.
    MTBF for me is not an estimation of how long an asset will last at all, for me it says more about the improvement/ decrease of the reliability of an asset or system.
    Your topic intrigued me as I am starting to very much agree about whether it is wise to use MTBF at all.
    I would be very excited if you could tell me your experience with other, similair and preferably more representative metrics.

    Greatings,

    Stefan

    1. Hi Stefan, you should be concerned as MTBF most likely is misleading or not representing the actual failure rate at any particular time of interest.

      Instead use reliability, probability of success at a specific duration. 98% reliable over 1 year, for example.

      Use multiple points in time, or better and you have the time to failure information, fit a Weibull distribution (or appropriate distribution) and have the entire picture of probability of failure over time in a CDF plot.

      Cheers,

      Fred

      1. Hi Fred,
        Thank you alot! I will have a look into that, this is very usefull and fun information for me to work with! Thanks again.
        Greetings,

        Stefan

  3. Hi Fred, I appreciate your site a lot. How important mission it is one can understand searching the internet for exmaples of MTTF calculation and FIT.
    I’ve started reading about hazard rate, failure rate and MTTF’s etc. but can’t find any advise how to interpret test data toward obtaining failure rate. Let me put here example:
    I’m testing 10 devices (nonrepairable system) over e.g. 400 hrs.
    Recorded failure times in hrs: {30, 45, 60, 90, 120, 180, 240, 300}, 2 devices survived.
    Can I say my failure rate is 8/(30+45+60+90+120+180+240+300+2*400) and MTTF as reciprocal of Failure rate? maybe even I shouldn’t even try to calculate failure rate from this data? Does this method imply any problems with reliability calculation? I agree that mean value for particular distribution yields different reliability but please advise how to process this data in correct way.
    I appreciate your feedback in advance.

    1. Hi Rafal, thanks for the note and example problem. While you can estimate the failure rate and MTTF as described it is not all that useful in most cases.

      Instead use a Weibull analysis (with so few data points Weibull is often a great starting point as it is versatile ) This will provide the probability of failure at various points in time.

      I’m traveling at the moment and have limited access, so will follow up later when I can either work out the problem for you, or point to a better reference and example.

      Cheers,

      Fred

      1. HI Fred.
        Thank you for your interest. Meanwhile I was sitting and struggling to understand meaning of Failure Rate and its interpretation. I think it can be good supplement to the previous question if I ask if when for example failure rate equal 0,004 fail/hr or in other words 4 fails per 1000hrs means 4 of them will fail every 1000 hrs assuming exponential distribution and constant hazard rate. It also means that if I had 4 components then I could expect none of them functioning after 1000 hrs but it also means that if I had 1000 components 4 of them will fail within 1000 hrs and 996 will remain healthy until next 1000 hrs left? I read somewhere failure rate example: FR=0.1 means 10% of population will fail every time stamp and in fact it plots exponential curve but in this case having specific amount of devices e.g. 1000 components, it lineary drops to 0 after 250 000 of hrs gone (1000 * 250) where 250 is mean time to fail. Maybe it shouldn’t be understood so straight forward? Maybe if it is an average value and follows assumed exponential pdf then we can say in average 4/1000hrs fails but in our case 37% will fail in first 250hrs and remaining 63% within the next 250000-250 = 249750 hrs. If this is correct I’m home if not I’m lost…

  4. Nice work here Fred!!
    what is the best formula to use in calculating MTBF? Average time between failures i.e (total operating time/number of failures) or Total time/number of failures?

    1. There are many definitions of what is and is not counted. I tend to use, if I cannot dissuade the use of anything else, the total operating time. If using total time, you are including the repair or replacement time. Best to use Availability directly if interested in uptime.

  5. Dear Fred,
    I work at a company where we are making a device wherein we are using several electronic components. The devices are in their trial phase and I want to calculate its mtbf. What I want to know that since it has not been more than 5-6 months since our first device was made,which method of calculating mtbf should I use, estimation or prediction? I have downloaded a software for mtbf prediction by ALD. If I want to calculate the mtbf by estimation how long do I need to collect data for to get a good idea of the failure rate.

    1. Hi Vivek,

      Pretty much doesn’t matter which method you use to find MTBF, as it is probably not useful for what you want to accomplish.

      What is it you need to understand about your device? How long will it last in some environment? How long, under what conditions, etc? Or do you need to provide feedback to your team on the demonstrated reliability to date? Or, do you need to find elements of the design to make it more robust or reliable?

      What is it your are trying to accomplish? What question is your team trying to answer?

      Real data is always better than a tabulated set of failure rate (ALD or vendors datasets included). If you device is expected to operate for 5 to 6 months and you have some number of devices running (maybe a few failures or not), you might be able to sort out a life estimate. If the device should run for 20 years, then unless you’ve been running accelerated life tests focused on the dominant failure mechanisms, you have very little data to help you estimate the reliability at 20 years.

      Parts count predictions are not useful to estimate the actual field reliability performance. Using just constant failure rates or MTBF values, you learn very little about how it will perform for your customers – most parts count based prediction methods even state they are not useful to estimate field performance. They can be useful to estimate relative changes in design or use conditions, and even that is suspect in many cases.

      If the desire is to determine if ‘the design is in the ballpark or close enough on reliability’ then predictions are not the right approach. Instead, determine what is likely to fail. Use a physics of failure approach and based on what is likely to fail, and understanding your use conditions, estimate the time to failure information you need.

      Bottom line, do not focus on calculating MTBF, instead understand the question(s) your team needs answered and work to answer those using reliability, availability, or other meaningful metrics.

      Cheers,

      Fred

Leave a Reply

Your email address will not be published. Required fields are marked *