We Need to Try Harder to Avoid MTBF

Just back from the Reliability and Maintainability Symposium and not happy. While there are signs, a proudly worn button, regular mentions of progress and support, we still talk about reliability using MTBF too often. We need to avoid MTBF actively, no, I mean  aggressively.

Let’s get the message out there concerning the folly of using MTBF as a surrogate to discuss reliability. We need to work relentlessly to avoid MTBF in all occasions.

Teaching reliability statistics does not require the teaching of MTBF.

Describing product reliability performance does not benefit by using MTBF.

Creating reliability predictions that create MTBF values doesn’t make sense in most if not all cases.

Avoid MTBF When Teaching Reliability Statistics

Sure it’s easy. The math and formulas are simplified, yet the loss is in promulgating the connection between reliability and MTBT. The Weibull distribution is not much more complex and is much more versatile. Weibull isn’t the only distribution, yet it prevents the oversimplification caused by using the exponentials distribution.

MTBF is not an easy or natural outcome when using a life distribution or non-parametric approach (excluding the exponential distribution). Most reliability engineering text and courses include the four-part definition of reliability, including the probability of success element. Let’s use that probability and associated duration through the course instead of MTBF.

If you attend a course or tutorial that includes the use of MTBF, here are few question to ask:

• Why are you using MTBF when we should not use it to describe most real world situations?
• Why are you making those simplifying assumptions?
• How does MTBF relate to defining reliability since it does not include a duration? (This one exposes the confusion around MTBF being a duration or failure free period)
• MTBF is not helpful here, what is the probability of success over a duration?

Finally, you really should ask how learning about MTBF is useful in any way and how is this course or tutorial of value.

Avoid MTBF on Datasheets and Product Descriptions

If you want to describe or understand the reliability performance of a product, then describe the probability of successful operation over specified durations with specific environmental and use conditions and functions. Provide meaningful information and when possible a model to translate different stress conditions to expected life performance.

MTBF alone is meaningless.

Here are few questions to ask when finding MTBF as a product description:

• What is the duration over which this is true?
• What data or information supports this MTBF value? (Is the value a database generated piece of fiction or the result of limited testing done to avoid any and all failures?)
• What is the reliability performance over <insert duration of interest>?
• How does the reliability change with time, stress, etc.?

Avoid MTBF Generating Software

Especially if the software defaults to creating MTBF values. Prediction software based on parts count approaches are especially prone to do this.

When I ask the vendors of such ‘tools’ they say they have to offer MTBF and they set it as the default as it is the customer’s request or expectation. ‘Give them what they want’ is the general response.

When I talk to consumers, clients, vendors, suppliers, or designers, they want a product that will survive over some duration with some relatively high probability. They may ask for MTBF believing that will provide the information related to what they want, yet we know MTBF doesn’t provide the necessary nor sufficient information concerning product reliability performance.

How about giving customers, et. Al. What they really want. They want to know the expected reliability, not MTBF.

If using or considering a software package that tends to offer MTBF here are few questions to ask:

• Is MTBF what you and your customer, etc. Really want to know?
• Does this software provide reliability as a function of time and/or stress?
• Does this software avoid using simplifying assumptions around a constant failure rate?

Ask the MTBF generating software vendor why they are wasting your time providing an application that you don’t want nor find useful. Sure it’s simple and quick to create a meaningless value (MTBF), thus the price really should reflect the offered value.

Summary

We can and should ask questions whenever we see the use of MTBF.

I heard a few and saw evidence of others approaching MTBF appropriately. Heard about organizations, standards, and courses moving away from or outright banning the use of MTBF. That is encouraging.

At the conference, a reliability conference, MTBF is still there. It shouldn’t be. With our questions and expectations to improve the reliability discourse, we can help our industry move toward talking about and teaching reliability without using MTBF.

We can do this.