Ask for failure dates not failure rates.

Just because the vendor provide the data convenient for an MTBF calculations should you settle?

No.

You have some questions to ask and some better information to gather. You may have a decision to make and using the best possible data helps you and your team make the right decision more often.

Datasheets, MTBF and FITs

For product from capacitors to pumps vendors are quick to provide either a FIT (failures in time, generally failures per 10⁹ hours) or MTBF (mean time between failures). And, of most customers that is sufficient.

Is that really sufficient?

No.

It is a rare data sheet that provides information on expected failure mechanisms, a model related stress and time to failure, or Weibull plot indicating the chaining nature of the failure rate as the device wears out.

This is the information we really need as reliability professional if we are going to advise our team on the options to make reliability improvements.

How to request reliability information

In order to get closer to the information you actually need, change the way you make the request. Instead of asking for reliability data, or failure rate information, ask for failure dates. [A student in my U of Maryland ENRE642 Reliability Engineering Management course suggested this change in wording.]

What we really want to know is:

• What is expected to fail and when in our application? This is very close to a complete reliability goal statement, yet focused on failures.
• What are the expected failure mechanisms? Will the failure of one element damage other elements of our product or not?
• What is the time to failure pattern (distribution)? When should we expect failures?
• And, what is the relationship between stress and time to failure? This for the advance folks, yet a proven and supported model between temperature, use and time to failure is key when developing a new product.
• What are the major factors that influence reliability?
• What causes variation in the time to failure?

If your team asks for failure dates instead of failure rates, imagine the change in the conversation with vendors that will occur. We might actually learn something useful and vendors will have to understand their product.

That would be useful.